improve mismatch install error situation

[rmarquis]

Prior to pacaur 4.4.0 (November 2015), the installation of built package was done though makepkg -i. As this flag installed all subpackages of a split package by default, the additional --pkg flag was used to selectively install the relevant subpackages of split packages.

However, this --pkg flag was removed in pacman 5.0 with the buggy ability to build individual packages, leaving no choice but to use pacman -U to install (split) packages correctly (#364) by passing the full path to the package file, including its full version for a robuster implementation. The version string is retrieved from the RPC interface, which itself retrieves it from the .SRCINFO file that is normally updated at the same time each PKGBUILD updates occur by packages maintainers.

Unfortunately, maintainers sometimes forget to update this .SRCINFO file, leaving the AUR interface and the RPC with obsolete information. Pacaur still relies on the retrieved RPC version string for installation. If a discrepancy is detected (expected built package not found), pacaur simply aborts and display the infamous "failed to install" message:

:: Installing X package(s)...
:: X package(s) failed to install.
:: ensure package version does not mismatch between .SRCINFO and PKGBUILD
:: ensure package name has a VCS suffix if this is a devel package

While some workaround are possible and even necessary for VCS packages (#428), the choice to error out with regular package is consciously done to incite users to report the issue to the maintainer in order to fix it.

In other words, I prefer to let AUR maintainers fix issues that should be fixed by them (in PKGBUILDs or outdated .SRCINFO) rather than implementing workarounds, and I am personally fine to bother and incite users to help maintain the AUR and its metadata. This seems to be, however, a controversial stance but I do consider it the lesser of two evils, considering the popularity of pacaur.

Now onto related issues and possible improvements:

• The implementation as currently done is very lazy: it's a quick hack implemented at installation time in the very place where the old makepkg -i --pkg operation occured. It should be possible to move this version check earlier, compare the version of all packages on the build queue together and error out much earlier (ideally before any build occurs);
• It should be possible to get --pkg or some variation of it back into makpekg. This was removed to prevent the ability to selectively build split packages, but the use case of selective installation does not seem to have been considered. There was a previous attempt to get it back, but it stayed unanswered.
• It is difficult to properly detect all VCS packages and some would still be impacted by this issue (grepping for -(git|hg|...) is insufficient to know whether a package is a devel one #507). Some packages behaves like VCS packages but actually aren't (see f.e. firefox-nightly or visual-studio-code-insiders, or libfpx currently fails to install #781 for a recent edge case). I am not sure what could be done here, apart from implementing the VCS trick (use makepkg --packagelist to retrieve updated VCS version #428) for all packages. This could potentially effectively bypass the issue for all packages, but could leave the door open to a much less reliable RPC metadata on the longer term.
• The ideal solution would be to find a way to prevent the .SRCINFO update mishap. This has been brought to the AUR dev team already (FS#46130), but only a very partial solution has been implemented so far.

[rmarquis]

This makepkg patch by eschwartz should alleviate the need to readd --pkg back into makepkg. It's not in master yet but shouldn't take long to be merged (#726).

Also, rework the error message. It's apparently "not honest enough", whatever that means.

[AladW]

It refers to this comment

You already trusted the PKGBUILD that late in the game. A more honest check would be to compare the .SRCINFO to the output of makepkg --printsrcinfo and abort on any mismatch, and do so after the user okayed the PKGBUILD but before going further. I would respect your decision if that was what you had done.

Also, I somehow missed that pacaur was already using makepkg --packagelist and that the SRCINFO hack only remains - to put it bluntly - for political reasons.

(That whole show happened not per se because of user complaints about metadata, but because of the escalation from mere complaints to actual harassement of AUR maintainers. In particular gstreamer0.10-base, where dozens of users kept filing the same comments and spamming pointless requests to the TUs - not exactly helped by comments such as "All requests to update this package are valid." on your behalf.)

About VCS packages, see FS#56602, in particular the last comment by Lukas:

There is support for automated searching, but not for automated building. I agree that having naming guidelines is a good idea...

[rmarquis]

Yeah, I've recently learned that two random guys fighting in a chat room with piss poor attitude apparently makes pacaur a political platform.

[AladW]

I like how you downplay the whole thing and reduce it to what happened one night on an IRC channel.

In the end I don't care how you write your software or how people use it - but if I see this kind of harassement to AUR maintainers again, especially for issues which have little to no impact on people using the supported tools (being makepkg), accounts will start to magically become suspended. And just to be clear - the idiotic, page-long bikeshed from both sides equally counts on this regard.

Anyway, I just wanted to get that out of the way. Thanks for your initiatives on improving the AUR.

[rmarquis]

I consider it yet another high in the recurrent shitshow, but it is indeed a chain of events that might be even traced back to the time this project became somewhat popular.

I'm not sure what's the point of your message, but I am glad if you feel better now.

This said, it has been clear to me for quite some time that the hassle of maintaining a popular helper is not worth the time nor the hassle. Without entering into the ugly details, this has become an unpaid job I dislike more than enjoy while I have clearly way too many other problems irl to have the luxury to participate in that shitshow any longer - unless it magically becomes a job that I dislike but that is at least handsomely remunerated.

The above still holds true. Looking at what should ideally be done for a possible rewrite didn't take it out of my mind - on the contrary. Since the current code has run out its course, it sounds like the perfect time to end it.

[AladW]

The above still holds true. Looking at what should ideally be done for a possible rewrite didn't take it out of my mind - on the contrary. Since the current code has run out its course, it sounds like the perfect time to end it.

You've been saying that for a while. Personally I think all the "user friendly" helpers are a burden to the community, especially yaourt and [archlinuxfr]. Removing them would probably just result in some crazy person forking the code - though that's out of your hands.

I don't think there's anything left for me to say here, so I'll just leave it that.