Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274550 > unrolled thread

question about apt upgrade facing locally build packages

Back to article view | Back to linux.debian.user

Contents

  question about apt upgrade facing locally build packages Patrice Duroux <patrice.duroux@gmail.com> - 2024-11-16 15:30 +0100
    Re: question about apt upgrade facing locally build packages <tomas@tuxteam.de> - 2024-11-16 16:00 +0100
      Re: question about apt upgrade facing locally build packages David Wright <deblis@lionunicorn.co.uk> - 2024-11-16 19:00 +0100
        Re: question about apt upgrade facing locally build packages <tomas@tuxteam.de> - 2024-11-16 19:30 +0100
          Re: Re: question about apt upgrade facing locally build packages Patrice Duroux <patrice.duroux@gmail.com> - 2024-11-16 21:00 +0100
            Re: Re: question about apt upgrade facing locally build packages <tomas@tuxteam.de> - 2024-11-17 07:50 +0100
            Re: question about apt upgrade facing locally build packages Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-11-20 10:10 +0100
            Re: Re: question about apt upgrade facing locally build packages Tim Woodall <debianuser@woodall.me.uk> - 2024-11-22 13:30 +0100
          Re: question about apt upgrade facing locally build packages Tim Woodall <debianuser@woodall.me.uk> - 2024-11-20 13:10 +0100
            Re: question about apt upgrade facing locally build packages <tomas@tuxteam.de> - 2024-11-20 13:20 +0100

#274550 — question about apt upgrade facing locally build packages

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:-).

Moreover, this is done without notifying "such dangerous case" to the
user but just like usual upgrading.It could be interesting to alert on
such upgrades if this was expected for security reasons (ie. not
matching some signature of the official package).

When there are many packages to upgrade it is difficult to see such
cases in the list and may lose the one locally installed.

Regards,
Patrice

patrice@kos-moceratops ~/l/debian> sudo dpkg -i pcsxr_1.9.94-6_amd64.deb
(Reading database ... 723322 files and directories currently installed.)
Preparing to unpack pcsxr_1.9.94-6_amd64.deb ...
Unpacking pcsxr (1.9.94-6) over (1.9.94-6) ...
Setting up pcsxr (1.9.94-6) ...
Processing triggers for mailcap (3.74) ...
Processing triggers for gnome-menus (3.36.0-1.1+b3) ...
Processing triggers for desktop-file-utils (0.27-2) ...
Processing triggers for man-db (2.13.0-1) ...
patrice@kos-moceratops ~/l/debian> sudo apt upgrade
...

Upgrading:
  pcsxr

Summary:
  Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 0
  Download size: 666 kB
  Freed space: 24.6 kB

Continue? [Y/n]
Get:1 https://deb.debian.org/debian sid/main amd64 pcsxr amd64 1.9.94-6 [666 kB]
Fetched 666 kB in 0s (1863 kB/s)
(Reading database ... 723322 files and directories currently installed.)
Preparing to unpack .../pcsxr_1.9.94-6_amd64.deb ...
Unpacking pcsxr (1.9.94-6) over (1.9.94-6) ...
Setting up pcsxr (1.9.94-6) ...
Processing triggers for desktop-file-utils (0.27-2) ...
Processing triggers for gnome-menus (3.36.0-1.1+b3) ...
Processing triggers for man-db (2.13.0-1) ...
Processing triggers for mailcap (3.74) ...
Scanning processes...
Scanning processor microcode...
Scanning linux images...

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

[toc] | [next] | [standalone]

#274553

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#274568

On Sat 16 Nov 2024 at 15:54:17 (+0100), tomas@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.

[toc] | [prev] | [next] | [standalone]

#274572

[Multipart message — attachments visible in raw view] — view raw

On Sat, Nov 16, 2024 at 11:53:25AM -0600, David Wright wrote:
> On Sat 16 Nov 2024 at 15:54:17 (+0100), tomas@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

[toc] | [prev] | [next] | [standalone]

#274578

> 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

[toc] | [prev] | [next] | [standalone]

#274587

[Multipart message — attachments visible in raw view] — view raw

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
> 

[toc] | [prev] | [next] | [standalone]

#274688

Patrice Duroux <patrice.duroux@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#274789

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.

[toc] | [prev] | [next] | [standalone]

#274690

On Sat, 16 Nov 2024, tomas@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), tomas@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)

[toc] | [prev] | [next] | [standalone]

#274692

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 20, 2024 at 12:04:42PM +0000, 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web