Skip to content

use nvchecker to check new version

Jump to bottom
Isaac Ge edited this page Jul 24, 2015 · 1 revision

nvchecker usage

Introduction

nvchecker developed by lilydjwg, is an easy-to-use tool to check if a new version of software has been released. Package Maintainers, I (Stephen Zhang / zsrkmyn) recommend you all use this tool to keep your packages in the repo up to date by finding which of them have new versions available.

About nvchecker

  1. Project Home: https://github.com/lilydjwg/nvchecker
  2. Project Documentation: https://github.com/lilydjwg/nvchecker/blob/master/README.rst
  3. Installation: It is available as nvchecker-git in our repo and the AUR. The following optional dependencies are recommended for access to HTTP and other repo types: python-pycurl, mercurial, git.

Abbreviated Instructions

Version Source Files

In the repo, there is a configuration file, nvchecker.ini, listing version sources for repo packages. When using Lilac, nvchecker will be fed version-source information from this file for each package that has a lilac.py to determine whether it needs to be updated. Although maintained for use with Lilac, nvchecker.ini can be used when running nvchecker manually as well. You may find it useful, however, to maintain a separate configuration file that only contains version-sorce records for packages you are interested in. Version source files can have any name and are passed to nvchecker on the command line.

###Keep the configuration file in sync with the repo Each record in the configuration file, nvchecker.ini, contains a package name (in square brackets) with information telling nvchecker how to determine the current version of that package, and is listed under the package maintainer's name. So, every time you add a new package to the repo, you should also add a corresponding record to this configuration file, under your name. If your name is not already in the configuration file, add it, being careful to use the following format: # Your Name <email> {{{1. Make sure to add the final {{{1, so that vim will fold configuration records by name. Whether you should remove the configuration record when you remove the package from the repo depends on the complexity of the record.

Most records in nvchecker.ini just have "aur =" as the configuration option under the package name because finding the latest version in the AUR is the default (blank) configuration. Such a simple record should be deleted when you remove the package from the repo. Other repo types can have complicated configuration information though, like URL, regex, shell command, git location and branch, etc. Rather than deleting complicated records, you should just comment them out for possible future use.

For detailed information about the options you can enter in each record of the configuration file, according to repo type, read Version Source Files

How to check if the repo packages are up to date

If you look at nvchecker.ini, you'll see that it is configured to find the old version info (listing what version of each package is currently in the repo) in a file named old_ver.txt, and to put the new version info into a file named new_ver.txt containing the latest versions available for those packages. Both files are expected to be found in the same directory as nvchecker.ini since no path is specified.

  1. Generate old_ver.txt Switch to your repo directory cloned from our github repo (cd ~/repo, for example), and simply use pacman -Sl archlinuxcn | awk '{print $ 2, $ 3}'> old_ver.txt to generate old_ver.txt. Please note that, unfortunately, some version information generated this way will not be in the same format detected by nvchecker. This package, nvchecker-git, is a good example of this issue. In old_ver.txt, it's currently listed as nvchecker-git v0.3.r33.g82c85f0-1 but in checking for the version on github, nvchecker just detected the date part and put that in new_ver.txt as nvchecker-git 20141103. There's no obvious way to tell if that's a new version or not.

  2. Generate new_ver.txt with nvchecker nvchecker.ini (again from your local copy of our repo directory).

  3. Generate a list of packages that have newer versions available with nvcmp nvchecker.ini. The previously mentioned issue where some version information is not in the same format will be obvious in this listing. For example, nvchecker-git currently shows up in the list of packages that have an update available as nvchecker-git v0.3.r33.g82c85f0-1 -> 20141103.

  4. Update old_ver.txt with nvtake nvchecker.ini <package that you just updated>. This will copy the version information for that package from new_ver.txt into old_ver.txt, so that it won't be listed again if you repeat the previous step to see what packages are left to be updated. Note that I (Stephen Zhang / zsrkmyn) have added both old_ver.txt and new_ver.txt to our repo .gitignore so that those files won't be added to our repo. To avoid mistakes, it is recommended to just repeat the first step to regenerate old_ver.txt after updating a package instead of using nvtake....

How to check if the packages you are interested in are up to date

The previous section demonstrates how to check all the packages in the repo, but how can you check only those packages that interest you (like, just the ones you built)? Of course, you could manually enter all your packages along with the current version into old_ver.txt, but if you've got a lot of packages, how can you automatically generate old_ver.txt so that it only includes your packages? This seems to be the question posed in the original wiki page I (Colin Keenan) have translated above from Chinese (with the help of Google Translate because I don't read or speak Chinese), but it is in a "To Do" section. There are many answers, but most would require that each package maintainer setup some files for that purpose beyond a configuration source-version file.

I have proposed a solution below that seems to be working for me. Anyone reading this who sees pitfalls/bugs/faster methods, please post the better solution. This works by finding all the packages in which you have done a git commit, and then searches for those packages using pacman -Ss to get the current version in our repo.

  1. cd ~/repo

  2. Make sure you have kept the configuration file in sync with the repo. If you've got too much to add by hand, automatically generate your personal source version file

  3. Make your own source-version configuration file Just cp nvchecker.ini ~/my.ini and edit ~/my.ini removing everybody else's packages. Or, automatically generate your personal source version file.

  4. Generate old_ver.txt so that it only contains packages you worked on git whatchanged --author=<name> | grep "^:" | cut -f2 | cut -f1 -d'/' | uniq | xargs -I% pacman -Ss "^%" | grep "^archlinuxcn/" | cut -f2 -d'/' | cut -f1,2 -d' ' | sort | uniq > ~/old_ver.txt Don't forget to replace <name> with a part of your name or email. For example, I would use 'colin'.

  5. cd ~

  6. Generate new_ver.txt nvchecker my.ini

  7. Generate a list of packages that have newer versions available with nvcmp my.ini.

  8. Update old_ver.txt with nvtake my.ini <package that you just updated> if the first step is too slow to repeat after finishing each update.

###Automatically generate your personal source version file

  1. git whatchanged --author=<name> | grep "^:" | cut -f2 | cut -f1 -d'/' | sort | uniq | xargs -I% printf "[%]\naur=\n\n" > ~/my.ini making sure to replace <name> with a part of your name or email.

  2. Copy and paste the following into the top of ~/my.ini, replacing the general info with your own (like, Colin Keenan <colinnkeenan@gmail.com>):

     [__config__]
 oldver = old_ver.txt
 newver = new_ver.txt
 

 # Your Name <email> {{{1

  3. Copy and paste the following at the end of ~/my.ini

     # unused & vim modeline {{{1
 # vim: se fdm=marker:

  4. Now you can use this file with nvchecker or copy the information into nvchecker.ini to keep it updated.

Clone this wiki locally