You are not logged in.

#1 2018-12-24 04:12:31

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Trying to avoid rebuilding a package on dependency update

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

#2 2018-12-24 04:44:39

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: Trying to avoid rebuilding a package on dependency update

cubethethird wrote:

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.

cubethethird wrote:

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

#3 2018-12-24 04:48:36

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Re: Trying to avoid rebuilding a package on dependency update

Thank you for the insights and clarification. I suspected incrementing the pkgrel wasn't advisable in these instances, and thus avoided doing so.

Offline

#4 2018-12-24 04:49:47

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: Trying to avoid rebuilding a package on dependency update

Why would it not be advisable - this is exactly what pkgrel is for.

PKGBUILD wiki page wrote:

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

#5 2018-12-24 04:58:52

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Re: Trying to avoid rebuilding a package on dependency update

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

#6 2018-12-24 05:03:44

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: Trying to avoid rebuilding a package on dependency update

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

#7 2018-12-24 05:06:36

cubethethird
Member
Registered: 2016-01-25
Posts: 61
Website

Re: Trying to avoid rebuilding a package on dependency update

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

#8 2018-12-24 05:49:55

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Trying to avoid rebuilding a package on dependency update

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

Board footer

Powered by FluxBB