You are not logged in.
I maintain the package e4rat-lite-git.
This one depends on boost/boost-libs, and when this is updated the package needs to be re-built.
I am no expert on package building, but am wondering if there would be a way to modify the package to prevent this.
The only suggestion I have received thus far is to version bump the package with each update, though I find this not very effective (not to mention generally annoying) as a solution.
I would expect there would be a way to dynamically link the libraries, though I am not sure how this would be accomplished, if possible.
Offline
The only suggestion I have received thus far is to version bump the package with each update,
That was an incorrect suggestion. It is up to users to rebuild their AUR packages as needed. You can (but are not required to) increment the pkgrel when a rebuild is called for. Do not increment the version unless there is actually a new version of the software you are packaging.
I would expect there would be a way to dynamically link the libraries...
You already are dynamically linking to them - which is why your binary needs to be updated whenever there is an ABI change and/or soname change in the libraries. You could statically link (in theory) and avoid this. But static linking, especially to something like boost, is far from trivial - and in some cases prohibited due to licensing.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Thank you for the insights and clarification. I suspected incrementing the pkgrel wasn't advisable in these instances, and thus avoided doing so.
Offline
Why would it not be advisable - this is exactly what pkgrel is for.
pkgrel
The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package.
Last edited by Trilby (2018-12-24 04:50:31)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
The reason I believed this is because, in this instance, the package itself hasn't been receiving any updates upstream, whereas boost gets updates relatively frequently. My impression is that it's somewhat counter-intuitive to be repeatedly "version bumping" the package with no actual changes simply to have it re-built. If that's the preferred method though, I would probably just write a script to automate the process.
Offline
Ah, no, that's precisely what I'm saying: do not increment the version if there are no upstream updates to e4rat-lite (and as it's a git package you wouldn't anyways). You can increment the package release number, though, as described in the above-quoted wiki to indicate a consequtive build of the same package.
Also I didn't say this is the preferred method. That is debatable (and is periodically debated). Personally I don't favor it. You are not required nor expected to do anything to your AUR package when a dependency is upgraded. It is up to users of AUR packages to rebuild their packages as needed. You can (optionally) increment the pkgrel to indicate to users that it is time to do so.
If users have made reasonable requests that you do something of this sort to tell them when they should rebuild the package, you can consider it. But if anyone has told you it is expected/required or suggested you are doing something incorrectly for not changing the PKGBUILD when boost is updated, tell them to take a hike: they are wrong.
Last edited by Trilby (2018-12-24 05:07:54)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Apologies. I meant to refer to the release number, not version number. If that's it's main purpose then that clarifies things for me.
Offline
Again, as Trilby said, it's not *required* to do anything, and certainly isn't a bug if you fail to.
But, personally, I *do* usually provide a pkgrel bump for my packages. Often you'll find though, for git packages, that there have been upstream commits since then. So you'll ultimately be bumping the git pkgver, and because makepkg resets the pkgrel to 1, re-bumping the pkgrel to 2.
Remember that if you do update the pkgrel of a git package, but there have been upstream updates which users have built, they will *not* see the update unless you've bumped the git pkgver as well. So if you are going to do one, you need to do both.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline