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.
Justus
[1] https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel [2] https://wiki.archlinux.org/index.php/Arch_User_Repository
Am 10.08.2017 12:33, schrieb Justus-dev@Piater.name:
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.
Justus
[1] https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel [2] https://wiki.archlinux.org/index.php/Arch_User_Repository
Hi Justus,
in my opinion, pkgrel is to be bumped when something with regard to the package changes, not for the sake of rebuild only. Keeping track of rebuilds is the users task, you could e.g. after a python update go through all remaining files in the old versions folder and initiate a rebuild of the corresponding packages. This is easily scriptable and should be regarded as usual update hygiene like ocassionally checking /var/cache/pacman and other tasks. Arch is not about fully automating everything and hiding the internal workings from the user. About the debugging: when a major update happens, you are usually informed about the necessary actions in the pacman output. Paying attention to that is not optional in Arch.
best Georg
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
On Thu, 10 Aug 2017 10:26:09 -0400 Eli Schwartz eschwartz@archlinux.org wrote:
pkgrel is supposed to monotonically increase on each rebuild of the package.
Which is completely invalid in the AUR. How is the maintainer supposed to keep the user from doing rebuilds in between?
On Thu, Aug 10, 2017 at 09:41:39AM -0500, Doug Newgard wrote:
On Thu, 10 Aug 2017 10:26:09 -0400 Eli Schwartz eschwartz@archlinux.org wrote:
pkgrel is supposed to monotonically increase on each rebuild of the package.
Which is completely invalid in the AUR. How is the maintainer supposed to keep the user from doing rebuilds in between?
Why, because pkgrel is now out of sync with the AUR? The user can just bump the release a minor version, which pacman handles just fine and will still see an upgrade the next time the maintainer updates the package.
Eli Schwartz wrote:
pkgrel is supposed to monotonically increase on each rebuild of the package.
When releasing a binary package, the pkgrel needs to be bumped if the resulting package's signature and/or checksums change (without changing the pkgver).
When releasing a PKGBUILD the requirement is not the same. The pkgrel should be bumped when rebuilding the old and new packages side-by-side would result in different packages with the same version due to e.g. metadata changes (desc, depends, license, url, etc.) or different build flags or installed files. Values that do not affect the final package can be changed without a pkgrel bump, such as checksums or download sources.
There is no rule on the AUR. Bumping the pkgrel is a workaround to help package manager that lack awareness of build dependencies. It doesn't hurt but it's not required. It is always the user's responsibility to manage rebuilds on the AUR.
Incidentally, there are tools to assist the user (e.g. pkg-list_unrebuilt script [1]).
Regards, Xyne
[1] https://xyne.archlinux.ca/projects/pkg_scripts/#help-message-pkg-list_unrebu...
aur-general@lists.archlinux.org