On 08/10/2017 06:33 AM, Justus-dev@Piater.name wrote:
Hi -
I keep running into problems caused by stale installations from the AUR, such as upgraded, ABI-incompatible dependencies or Python packages still installed under /usr/lib/python3.5/ where they are no longer found since the move to python3.6.
My understanding is that in such situations, the affected packages should bump pkgrel to force rebuild and reinstall, even if the source and the rest of the PKGBUILD remain unchanged.
Is this understanding correct? If so, can this be clarified in places such as [1][2] where people cannot miss it?
Confronted with this issue, some maintainers advise their users to just rebuild by hand, but that defeats part of the purpose of package management systems. I don't want to have to debug weird run-time errors one by one, trace the problem to this trivial issue, and then solve each of them by manual rebuild.
The problem is that there really isn't an official rule. Some people feel that "users should know and check for themselves", some people feel that maintainers should be responsible for making sure people know to upgrade. My personal feeling on the matter is that both of these arguments are completely missing the point. pkgrel is supposed to monotonically increase on each rebuild of the package. If the maintainer doesn't do that on the AUR, then users would have to do that themselves, by editing the PKGBUILD. As a result, there is a lousy choice between not knowing when the maintainer pushes a different pkgrel update because e.g. changed dependencies/build() function, and having no sane upgrade path but being forced to reinstall the same $pkgver-$pkgrel (and among other things, this will break the model used by aurutils). To my great displeasure, I have no actual way of enforcing reason on the entire world. :D -- Eli Schwartz