AUR web interface

**This is the bug tracker for the AUR web interface.**

Use this tracker to report bugs or make feature requests regarding the behaviour or implementation of the AUR software.
Please read the Reporting Bug Guidelines before filing a new task.

- Please report bugs related to Arch Linux official packages here:
- Please report bugs for [community] packages here:
- For any packages in the AUR contact the maintainer or leave a comment on the package's detail page.

Source Code:

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
Task Type Feature Request
Category Backend
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.6.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No


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

Comment by Lukas Fleischer (lfleischer) - Tuesday, 05 December 2017, 20:39 GMT
AUR helpers are something we do not support and do not recommend using.
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 05 December 2017, 21:16 GMT
Sorry for the wrong task type…

Why is there an RPC then? Are people supposed to use it manually?
Comment by Remy Marquis (Spyhawk) - Tuesday, 05 December 2017, 21:36 GMT
Just my two cents: I do feel that having a naming guideline for VCS-like packages would be both much simpler and more elegant for helpers support.
Comment by Lukas Fleischer (lfleischer) - Wednesday, 06 December 2017, 08:12 GMT
There is support for automated searching, but not for automated building. I agree that having naming guidelines is a good idea...
Comment by Alad Wenter (Alad) - Wednesday, 10 January 2018, 23:25 GMT
How would such naming guideline be implemented? There's over 10k packages using -git alone...
Comment by Remy Marquis (Spyhawk) - Thursday, 11 January 2018, 10:04 GMT
There is no need to have such naming guideline for VCS packages. It'd be only required for VCS-like packages, so a simple name parsing could be relied upon (see point 2 in OP).
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).
Comment by morganamilo (morganamilo) - Tuesday, 20 February 2018, 03:00 GMT
I think a better way to check if a package is VCS-like is to check if the pkgbuild contains a pkgver function.

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.
Comment by Eli Schwartz (eschwartz) - Tuesday, 20 February 2018, 07:05 GMT
That would first require you to convince the pacman maintainer that this merits extending the makepkg format, so now you have to convince *two* projects to add a feature. And it still wouldn't work, as not every package with a pkgver() function is a VCS package.

(Some of them check out a specific commit, then use pkgver() to autogenerate the `git describe` version of the pkgver for public use.)
Comment by morganamilo (morganamilo) - Tuesday, 20 February 2018, 07:26 GMT
Yeah I thought it probably wouldn't be worth the effort. Also I didn't think about the latter point.

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.