grepping for -(git|hg|...) is insufficient to know whether a package is a devel one

[anntzer]

I maintain https://aur.archlinux.org/packages/git-remote-hg, which is considered by pacaur as a --devel package, probably because it ends with -hg... but that's the actual name of the program (https://github.com/fingolfin/git-remote-hg).
Perhaps the presence of a pkgver() should be used to confirm that a package is indeed a --devel package.

[rmarquis]

That's unfortunate, but as pacaur solves deps and look up devel packages before downloading them, this looks like a wontfix. The package won't be updated anyway, so this is a minor annoyance only.

[anntzer]

Indeed, I'm suggesting a second filtering step after downloading the packages. But I agree it may be a bit overkill and also better solved by proper metadata in .SRCINFO.

[rmarquis]

My point was that the packages are downloaded after the main prompt. Everything is done using the RPC before the user agrees to continue.

Beside, using pkgver() in the PKGBUILD for detecting if a package is in fact a VCS package is a no go from my side. I could parse the .SRCINFO file in some way, but what should pacaur be looking for?

[anntzer]

Indeed, I am suggesting that the issue may be better solved by adding another field to .SRCINFO instead.

[anntzer]

Actually I just realized there's an easy way to improve the detection: VCS packages should have at least one SKIP entry in their checksums. While not there may still be some false positives, I think they should be pretty rare.

[rmarquis]

Many false positive vs one package that doesn't behave correctly? Still sounds like a wontfix...

[anntzer]

Sorry if I wasn't clear...
Currently the situation is: packages whose name end with -{git,hg,...} and are not VCS packages are mis-identified as VCS packages.
With the proposed fix, the situation would be: packages whose name end with -{git,hg,...}, who have a SKIP in their checksums and are not VCS packages are misidentified as VCS packages (the "false positives"). So it's strictly an improvement.

While nothing can prevent someone from uploading such a package to the AUR, I think they should be rare to non-existent (my comment above), because I believe the only valid reason to use a SKIP in the checksums is if the sources are going to be changing faster than the PKGBUILD itself -- i.e., a VCS package.

[rmarquis]

Ah, I see what you mean now. I've tried to push a quick fix in 5adb93e, but it seems the issue requires a much deeper code rewrite to make this hack work. The internal logic isn't designed to filters out packages once they passed the "need update" check, which is done through the RPC interface (and where the complete metadata cannot be checked). This is honestly not worth the effort.

Instead, the RPC should be expanded, so the filtering could be done in the first step, with the advantage that the main prompt could also be fixed.

See relevant FS#48796.

[ArchangeGabriel]

@rmarquis: I don’t see how this linked FS is relevant.

However, after reading around this, here is a proposal:
– detect presence of pkgver() at .SRCINFO generation time, add a tag like haspkgver to .SRCINFO,
– expose this over RPC.

Then, AUR helpers could make use of this flag to know they’re dealing with a PKGBUILD giving different result depending on compilation date.

Would that suits you?

[rmarquis]

Unfortunately, this wouldn't cover many existing edge cases. There are "VCS-like" (nighlty, snaphshot, dev, ...) packages that don't rely on pkgver() at all.

What doesn't work:

• relying on name parsing
• relying on pkgver()
• relying on VCSCLIENTS field of makepkg.conf

All have downsides. What we need is something like a isvcspkg field in .SRCINFO that is automatically enabled for supported VCS types, and that can be optionally enabled manually. Adding such a field is however very-helpers centric: even if all helpers developers require such a field, I am not sure this could be pushed upstream as helpers are unsupported.

[ArchangeGabriel]

OK, so I guess trying to be clever won’t work indeed. So a isvcspkg populated on pkgver (unless they are false positive too?) + eventually VCSCLIENTS (do you have good example(s) of non VCS packages using a VCSCLIENTS?), and ability to override that should do it.

Regarding support: well, helpers are not supported sure, but so is the AUR (it’s in its name). I’ll try to get this discussed amongst TU, I’ll keep you updated.

[rmarquis]

It is indeed possible for a PKGBUILD to refer to a specific VCS commit without being a VCS package itself (but thus requiring a VCS client to install the package). I've seen a handful over the years but cannot tell you which ones they are. I am however not aware of any non VCS packages that uses pkgver().

By VCSCLIENTS, I mean using that field to add custom VCS types, and then parsing the name extension as usual. In the past, I considered parsing that array instead of hardcoding the -git, -svn, -hg... extension in the code, so users could add their own -snapshot or similar, but that eventually resulted in adding more complexity without solving any existing issue (false positive in most cases).

[ArchangeGabriel]

It is indeed possible for a PKGBUILD to refer to a specific VCS commit without being a VCS package itself (but thus requiring a VCS client to install the package). I've seen a handful over the years but cannot tell you which ones they are. I am however not aware of any non VCS packages that uses pkgver().

Found one for both: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ring-daemon. Though I’m not use what the pkgver() things bring here.

So I think we’re going for a checkbox in the AUR website that is exposed over the RPC. Adding this to the .SRCINFO looks a bad idea, because it would have to be manual while most people automatically generate their .SRCINFO. Also this is a value I do not expect to change during the lifetime of the PKGBUILD, so it could be set on the interface.

[rmarquis]

Thanks for the input. Yes, modifying the .SRCINFO file manually has always been a bad idea - guess it was clear in my mind that this would be an additional option in the PKGBUILD that would then be automatically written into the .SRCINFO.

If that option is not relevant to repo package but specific to AUR only, then an interface option might be the best solution. Thanks for taking care of asking upstream!

@AladW FYI ^

[rmarquis]

@ArchangeGabriel Just curious, is there any news from this feature? Or any archived discussion about it, for the matter? I haven't seen anything on ML or flyspray.

[ArchangeGabriel]

Yes, sorry. Discussions happened in IRC (TU channel). This was heavily debated (including whether it should be in .SRCINFO or the web interface), in the end we agreed that I should open a FR on flyspray and leave the decision up to Lukas (I need to review the logs for the details). But before that, I need to review the ToS for the AUR, since Lukas told us this was the #1 priority regarding the AUR.

[colemickens]

I'm confused why taking these steps in my upgrade script does not work around the problem:

pacaur -R visual-studio-code-insiders --no-confirm
rm -rf ~/.cache/pacaur/visual-studio-code-insider
pacaur -S visual-studio-code-insiders --noconfirm

edit: Oh, I guess maybe pacaur is completely unable to install it. I'd thought it was just upgrades?

[rmarquis]

@colemickens Yes, the installation part is problematic. Stay tuned, I'll open a new issue about this later today.

[ArchangeGabriel]

At last: https://bugs.archlinux.org/task/56602

[rmarquis]

Looks like this will be a wontfix indeed.

I can't say I disagree with Lukas - I feel having a new naming guideline for VCS-like packages would be both much simpler and more elegant for helpers support. That wouldn't solve the cases like git-remote-hg above, but these are very rare outliers.

Thanks for filing the request. Closing now.

[rmarquis]

If we were to propose a naming guideline, where should this happens? And which extension(s) would be adequate?

In addition to the regular VCS -git, -hg, -svn, -bzr, -cvs and -darcs extensions, pacaur supports the -nightly extension which is quite common. The -daily extension could also be added (though only 3 packages use it), but -snapshot results in too many false positives (see #383 (comment)).

I'm also unsure if a naming scheme could be enforced, but having some "official" guideline would be a good first step.