search

rmarquis / pacaur

[unmaintained] An AUR helper that minimizes user interaction
https://bbs.archlinux.org/viewtopic.php?pid=1755144#p1755144
ISC License
796 stars 113 forks source link

libfpx currently fails to install #781

Closed dbermond closed 6 years ago

dbermond commented 6 years ago
Version
$ pacaur -v
pacaur 4.7.10
Description

libfpx currently builds fine with makepkg -o && makepkg -es but fails to install with pacaur.

It builds fine with pacaur, but fails at the install step with:

$ pacaur -S libfpx
...
:: Installing libfpx package(s)...
:: libfpx 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

Upstream libfpx does not provide a download archive of previous versions. It provides only the latest version. Being such, the PKGBUILD has a pkgver that is dynamically adjusted at build time if there is a new upstream release in order to allow the user to build and install the package even if there is a new upstream release.

Otherwise, package would fail to build when a new upstream release is made and the PKGBUILD is not yet updated, and not always the package maintainer can handle the version upgrade in the proper time.

I suppose that this issue occurs only in the case that there is a new upstream release and the package is not yet updated.

rmarquis commented 6 years ago

I suppose that this issue occurs only in the case that there is a new upstream release and the package is not yet updated.

No, the issue is that the AUR still sees the package version as 1.3.1.9-1, as displayed on the AUR page. This is also the version provided by the RPC interface that pacaur solely relies on by design for a bunch of different reasons, and which is obsolete in this case.

This version number is provided through the .SRCINFO file, which is normally updated at the same time the pkgver in the PKGBUILD is updated.

Though this is a edge case, I don't think there is a reason not to use a proper pkgver, even if upstream doesn't provide old archives (though that is a real shame).

dbermond commented 6 years ago

Thank you for the reply.

Though this is a edge case, I don't think there is a reason not to use a proper pkgver, even if upstream doesn't provide old archives (though that is a real shame).

In a package with a similar situation (imagemagick-full), people started to report broken package in the situation where there was a new upstream release and I could not yet update the package. This is an uncomfortable situation, because packages should continue to build fine even when being out-of-date, otherwise package will be broken every time that there is a new upstream release (and imagemagick releases new versions very frequently!). So I changed PKGBUILD to this dynamic pkgver schema and followed libfpx with the same logic.

I have updated libfpx to version 1.3.1.10, which is the version currently available at upstream, and pacaur installs it fine. But it would be good to allow installation with pacaur when the package is out-of-date too.

Glad to see that you added this to the '4.8.x new features' milestone. I hope this can be addressed in the future.

dbermond commented 6 years ago

Closing as this is now working with the up-to-date PKGBUILD version 1.3.1.10.

Thanks again.