Re: Re: question about apt upgrade facing locally build packages
On Sat, 16 Nov 2024, Patrice Duroux wrote: That's why I ended up with the suffix and letting the sysadmin (often me, with a different hat on ;-) making that preference explicit in the APT machinery. But could it be the a nice feature for apt to have a list apart on the upgrading (I would say then 'replacing') of such cases? User can be alerted more easily during apt upgrade that some packages with a same version could be replaced by the Debian archive ones. apt list --replaceable apt upgrade --no-replaceable :-) Note that it could be replacement from configured alternative source archives. But pinning does this for you. Pin your local packages at >500 and they will not be replaced (assuming defaults). Although having the same version number is, IMO, a bug and apt may behave 'oddly' - I haven't tried. If I patch a bookworm package then it gets a +~tjw12r1 added to the version. This is higher than the one in official debian but (hopefully) lower than any new version in debian. And my local repo is pinned at 995, so a new, higher version in debian doesn't replace my version unless I force it.
Re: question about apt upgrade facing locally build packages
On Wed, Nov 20, 2024 at 12:04:42PM +, Tim Woodall wrote: > That's what I do too. > > +~tjw12r1 > if I've patched the current version. > ~tjw12r1 if I've backported a higher version. > > I scan for newer versions in debian and auto-rebase my changes (unless > the rebase fails) so I'm rarely more than a day or two behind on > security fixes. [...] Nice writeup, thanks. Could that be Wiki material? Cheers -- tomás signature.asc Description: PGP signature
Re: question about apt upgrade facing locally build packages
On Sat, 16 Nov 2024, to...@tuxteam.de wrote: On Sat, Nov 16, 2024 at 11:53:25AM -0600, David Wright wrote: On Sat 16 Nov 2024 at 15:54:17 (+0100), to...@tuxteam.de wrote: On Sat, Nov 16, 2024 at 03:11:37PM +0100, Patrice Duroux wrote: On Sid, building and installing locally modified packages for testing at the same version as in the archive, I am surprised that apt upgrade will reinstall any of those installed by the one from the archive. I did not remember such a "feature" in the past, unless my memory plays tricks on me:-). I think you should change the package version (and thus the name) if you make local changes. ISTR that I added some ~local0 suffix. Then you can talk to your package manager about it (e.g. pinning,etc.) I found adding an epoch number was the simplest surefire method, as: . it's the most significant field in the version number, . you can leave the version number unchanged as an indication of the unmodified source, . a descriptive suffix is fine, but no help against upgrades. I was in this deliberation too, and came to the conclusion that sometimes you want a newer version overriding yours (perhaps you expect Debian's fix to be more important than yours, perhaps you even expect theirs to supersede yours), while sometimes you don't. That's why I ended up with the suffix and letting the sysadmin (often me, with a different hat on ;-) making that preference explicit in the APT machinery. That's what I do too. +~tjw12r1 if I've patched the current version. ~tjw12r1 if I've backported a higher version. I scan for newer versions in debian and auto-rebase my changes (unless the rebase fails) so I'm rarely more than a day or two behind on security fixes. r1 -> r2 etc if I rebuild a package for any reason. That weird +~ is to take account of nmus and ensuring that the next debian version is always higher than mine. I got caught out when a +deb security fix looked before my +tjw version so my system didn't notice that 'upstream' had a fix. tim@einstein(6):~ (none)$ apt-cache policy tgt tgt: Installed: (none) Candidate: 1:1.0.85-1+deb12u1+~tjw12r1 Version table: 1:1.0.85-1+deb12u1+~tjw12r1 995 995 http://aptmirror.home.woodall.me.uk/local bookworm/main amd64 Packages 1:1.0.85-1+deb12u1 500 500 http://deb.debian.org/debian bookworm/main amd64 Packages Not sure if this was a case but it was a recent nmu that added a +deb that could have been missed. (the maintainer appears mia so I reported the bug upstream but not in debian)
Re: question about apt upgrade facing locally build packages
Patrice Duroux writes: > But could it be the a nice feature for apt to have a list apart on the > upgrading > (I would say then 'replacing') of such cases? > User can be alerted more easily during apt upgrade that some packages with a > same version could be replaced by the Debian archive ones. Isn't apt-mark the thing you can use for this? Run apt-mark hold on any package you don't want upgraded. Remove the hold when you do want them upgraded again.
Re: Re: question about apt upgrade facing locally build packages
On Sat, Nov 16, 2024 at 08:41:24PM +0100, Patrice Duroux wrote: > > > That's why I ended up with the suffix and letting the sysadmin > > (often me, with a different hat on ;-) making that preference > > explicit in the APT machinery. > > But could it be the a nice feature for apt to have a list apart on the > upgrading > (I would say then 'replacing') of such cases? > User can be alerted more easily during apt upgrade that some packages with a > same version could be replaced by the Debian archive ones. > apt list --replaceable > apt upgrade --no-replaceable > :-) > Note that it could be replacement from configured alternative source archives. That sounds attractive, but I fear that it is practically unfeasible: whether a package is "replaceable" or not will depend a lot on "context", among other things on which other packages you have installed (that might be decided based on the dependency graph, but I fear it won't be sufficient), and on what use you are making of the installed packages (that can't be decided automatically). But it's interesting to ponder about such a kind of problem :-) Cheers -- tomás > signature.asc Description: PGP signature
Re: Re: question about apt upgrade facing locally build packages
> That's why I ended up with the suffix and letting the sysadmin > (often me, with a different hat on ;-) making that preference > explicit in the APT machinery. But could it be the a nice feature for apt to have a list apart on the upgrading (I would say then 'replacing') of such cases? User can be alerted more easily during apt upgrade that some packages with a same version could be replaced by the Debian archive ones. apt list --replaceable apt upgrade --no-replaceable :-) Note that it could be replacement from configured alternative source archives. Regards, Patrice
Re: question about apt upgrade facing locally build packages
On Sat, Nov 16, 2024 at 11:53:25AM -0600, David Wright wrote: > On Sat 16 Nov 2024 at 15:54:17 (+0100), to...@tuxteam.de wrote: > > On Sat, Nov 16, 2024 at 03:11:37PM +0100, Patrice Duroux wrote: > > > > > > On Sid, building and installing locally modified packages for testing > > > at the same version as in the archive, I am surprised that apt upgrade > > > will reinstall any of those installed by the one from the archive. I > > > did not remember such a "feature" in the past, unless my memory plays > > > tricks on me:-). > > > > I think you should change the package version (and thus the name) if you > > make local changes. ISTR that I added some ~local0 suffix. Then you can > > talk to your package manager about it (e.g. pinning,etc.) > > I found adding an epoch number was the simplest surefire method, as: > . it's the most significant field in the version number, > . you can leave the version number unchanged as an indication > of the unmodified source, > . a descriptive suffix is fine, but no help against upgrades. I was in this deliberation too, and came to the conclusion that sometimes you want a newer version overriding yours (perhaps you expect Debian's fix to be more important than yours, perhaps you even expect theirs to supersede yours), while sometimes you don't. That's why I ended up with the suffix and letting the sysadmin (often me, with a different hat on ;-) making that preference explicit in the APT machinery. Cheers -- t signature.asc Description: PGP signature
Re: question about apt upgrade facing locally build packages
On Sat 16 Nov 2024 at 15:54:17 (+0100), to...@tuxteam.de wrote: > On Sat, Nov 16, 2024 at 03:11:37PM +0100, Patrice Duroux wrote: > > > > On Sid, building and installing locally modified packages for testing > > at the same version as in the archive, I am surprised that apt upgrade > > will reinstall any of those installed by the one from the archive. I > > did not remember such a "feature" in the past, unless my memory plays > > tricks on me:-). > > I think you should change the package version (and thus the name) if you > make local changes. ISTR that I added some ~local0 suffix. Then you can > talk to your package manager about it (e.g. pinning,etc.) I found adding an epoch number was the simplest surefire method, as: . it's the most significant field in the version number, . you can leave the version number unchanged as an indication of the unmodified source, . a descriptive suffix is fine, but no help against upgrades. Cheers, David.
Re: question about apt upgrade facing locally build packages
On Sat, Nov 16, 2024 at 03:11:37PM +0100, Patrice Duroux wrote: > Hi, > > On Sid, building and installing locally modified packages for testing > at the same version as in the archive, I am surprised that apt upgrade > will reinstall any of those installed by the one from the archive. I > did not remember such a "feature" in the past, unless my memory plays > tricks on me:-). I think you should change the package version (and thus the name) if you make local changes. ISTR that I added some ~local0 suffix. Then you can talk to your package manager about it (e.g. pinning,etc.) Cheers -- t signature.asc Description: PGP signature
