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

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZziyEgAKCRAFyCz1etHa Rm35AJ4rAj5MKJILDLkpyfnFFnQt5NsGjgCeP3yPWgndru0ndeEq4TZy7JHIDgY=
=dOKC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZzjiiwAKCRAFyCz1etHa Rg7OAJ9v/R1NGSiv17s0Az+OVUQy+QhX5wCfUA/fxEWnw/6xxn8ugAVlweFd5Ic=
=D74p
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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


-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZzmR/gAKCRAFyCz1etHa RrgTAJ9yptbnM02LMYDZDkshmVQ+VRgrkgCfT7MhEbf0jKe6UXSSXaSLpUrCPPA=
=4C3E
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZz3TJQAKCRAFyCz1etHa RlRCAJ443mdrzjFEaHiBuFVv76ss6XiAEQCeKxHkindRDIRNFINsNWrM+IYYmEg=
=Av83
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)