FS#56602 - Add a checkbox field on AUR web to tell whether a package is “VCS-like” and expose it in the RPC.
Attached to Project:
AUR web interface
Opened by Bruno Pagani (ArchangeGabriel) - Tuesday, 05 December 2017, 19:59 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 05 December 2017, 20:14 GMT
Opened by Bruno Pagani (ArchangeGabriel) - Tuesday, 05 December 2017, 19:59 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 05 December 2017, 20:14 GMT
|
Details
Overview: the AUR is filled with packages that are either
VCS one (-git,-hg,-svn…) or “VCS-like” (those are the ones
having nightly builds, like firefox-nightly for instance).
The problem is that AUR helper have no reliable way to
detect all of them (and thus propose them for upgrade
through a `--devel` flag for instance), since every method
has caveats. Indeed:
– relying on the use of VCSCLIENTS from makepkg.conf means you miss VCS-likes; – relying on -git/-hg/-svn in the pkgname mean that you miss the VCS-likes, and there is no solution in this direction to get all of them since they do not all include some magic word like -nightly in their names (see visual-studio-code-insiders for instance —what would you take?); – relying on the existence of a pkgver() function is not enough, they are packages not relying on a pkgver() function, e.g. having LATEST has pkgver, but also false positives (see ring-daemon for instance). Solution: have a “Is VCS/Nightly package“ checkbox in the Maintainer interface, and expose it on the RPC. This way helpers can easily get which packages are affected. |
This task depends upon
Why is there an RPC then? Are people supposed to use it manually?
A good start is to have such VCS-like packages be named with a "-nightly" extension as many already use it, but more than one extension could be available (-daily/-snapshot/...).
To avoid false positive, it might also be a good idea to recommend *not* using such VCS or VCS-like extension in package name when the upstream project use it, but so far I've seen only one package doing so (git-remote-hg).
That would require makepkg to be updated to have some sort of 'isvcs' field in the srcinfo and then the RPC to be updated to expose it. So maybe not worth the effort but I would like to see it.
(Some of them check out a specific commit, then use pkgver() to autogenerate the `git describe` version of the pkgver for public use.)
The idea of a checkbox seems a little annoying and I would prefer an automated method but alas I can't think of another. So checkbox is probably the way to go if this is to get implemented.