Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Apt pinning.
32 views
Skip to first unread message
Tim Woodall
Nov 27, 2021, 6:00:05 AM11/27/21
to
Can anyone tell me exactly what this Pin line I have actually does - or
even better point me to a webpage that has more than "if you want to do
this use this" type of example?
(FTAOD I know that this isn't right and is inconsistent but before I
start changing it I want to really understand what it's currently doing)
I have a local repository:
Codename: buster
Components: main
Date: Thu, 25 Nov 2021 19:42:12 +0000
Description: Debs for local installing
Label: local debs
Origin: local debs
Suite: oldstable
And I have a pin (which I've failed to update since bullseye became
stable hence the a=stable)
Package: *
Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
Pin-Priority: 900
What I want this to do is hold any package in my local repository even
if a newer version is present in debian. My local repository has patched
packages for various reasons - e.g.
linphone/oldstable,now 3.12.0-3+tjw10r1 amd64 [installed]
linphonec in buster has a bug that causes a core on answering a call.
I've applied the patch locally. Were a new buster build to happen
(unlikely now but not impossible if there's a serious security issue
found) I'd want my local version to stay until I patch the new version.
This pin has worked successfully for me throughout buster's lifetime -
however when looking at it now to correct that a=stable I noticed that
https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html suggests
that I should be pinning at 990, not 900.
Also, I don't know if this pin is working with a=stable or it's actually
not doing anything useful any more. I cannot find anything that tells me
how the Pin: line actually matches.
I don't even know whether the options on that Pin line are AND or ORed
together. The example on the webpage has:
Package: *
Pin: release v=2.2*,a=stable,c=main,o=Debian,l=Debian
Pin-Priority: 1001
When debian went from v2.2 potato to v3 woody, would this pin stop
working? Because woody would be stable and potato oldstable at that
point.
I'm trying to solve a (minor) problem I'm having during upgrades from
buster to bullseye where I've backported make from bullseye to buster.
So on my buster systems I have:
make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed]
while once I've upgraded to bullseye I want to "downgrade" from my
backported package to make 4.3-4.1 and then continue to track bullseye.
I'm trying to work out what Pin line I want (ideally generic rather than
package specific - dump has exactly the same feature) but at the same
time I do not want my buster systems to install squid 4.6-1+deb10u7
(should it ever be created) over my patched 4.6-1+deb10u6+tjw10r1 but
instead hold my patched package until I patch deb10u7.
(ditto bullseye where I have squid/stable,now 4.13-10+tjw11r1)
For now I just manually apt-get install make=4.3-4.1 to fix it. But if
make built on buster had failed to work on bullseye then my package
could have made a mess of the upgrade if any packages are using make
during configuation.
Tim.
even better point me to a webpage that has more than "if you want to do
this use this" type of example?
(FTAOD I know that this isn't right and is inconsistent but before I
start changing it I want to really understand what it's currently doing)
I have a local repository:
Codename: buster
Components: main
Date: Thu, 25 Nov 2021 19:42:12 +0000
Description: Debs for local installing
Label: local debs
Origin: local debs
Suite: oldstable
And I have a pin (which I've failed to update since bullseye became
stable hence the a=stable)
Package: *
Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
Pin-Priority: 900
What I want this to do is hold any package in my local repository even
if a newer version is present in debian. My local repository has patched
packages for various reasons - e.g.
linphone/oldstable,now 3.12.0-3+tjw10r1 amd64 [installed]
linphonec in buster has a bug that causes a core on answering a call.
I've applied the patch locally. Were a new buster build to happen
(unlikely now but not impossible if there's a serious security issue
found) I'd want my local version to stay until I patch the new version.
This pin has worked successfully for me throughout buster's lifetime -
however when looking at it now to correct that a=stable I noticed that
https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html suggests
that I should be pinning at 990, not 900.
Also, I don't know if this pin is working with a=stable or it's actually
not doing anything useful any more. I cannot find anything that tells me
how the Pin: line actually matches.
I don't even know whether the options on that Pin line are AND or ORed
together. The example on the webpage has:
Package: *
Pin: release v=2.2*,a=stable,c=main,o=Debian,l=Debian
Pin-Priority: 1001
When debian went from v2.2 potato to v3 woody, would this pin stop
working? Because woody would be stable and potato oldstable at that
point.
I'm trying to solve a (minor) problem I'm having during upgrades from
buster to bullseye where I've backported make from bullseye to buster.
So on my buster systems I have:
make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed]
while once I've upgraded to bullseye I want to "downgrade" from my
backported package to make 4.3-4.1 and then continue to track bullseye.
I'm trying to work out what Pin line I want (ideally generic rather than
package specific - dump has exactly the same feature) but at the same
time I do not want my buster systems to install squid 4.6-1+deb10u7
(should it ever be created) over my patched 4.6-1+deb10u6+tjw10r1 but
instead hold my patched package until I patch deb10u7.
(ditto bullseye where I have squid/stable,now 4.13-10+tjw11r1)
For now I just manually apt-get install make=4.3-4.1 to fix it. But if
make built on buster had failed to work on bullseye then my package
could have made a mess of the upgrade if any packages are using make
during configuation.
Tim.
Dan Ritter
Nov 27, 2021, 8:10:05 AM11/27/21
to
Tim Woodall wrote:
> Can anyone tell me exactly what this Pin line I have actually does - or
> even better point me to a webpage that has more than "if you want to do
> this use this" type of example?
>
> (FTAOD I know that this isn't right and is inconsistent but before I
> start changing it I want to really understand what it's currently doing)
>
> I have a local repository:
>
> Codename: buster
> Components: main
> Date: Thu, 25 Nov 2021 19:42:12 +0000
> Description: Debs for local installing
> Label: local debs
> Origin: local debs
> Suite: oldstable
>
> And I have a pin (which I've failed to update since bullseye became
> stable hence the a=stable)
>
> Package: *
> Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
> Pin-Priority: 900
man apt_preferences # go ahead and read it, it's well-organized
> Can anyone tell me exactly what this Pin line I have actually does - or
> even better point me to a webpage that has more than "if you want to do
> this use this" type of example?
>
> (FTAOD I know that this isn't right and is inconsistent but before I
> start changing it I want to really understand what it's currently doing)
>
> I have a local repository:
>
> Codename: buster
> Components: main
> Date: Thu, 25 Nov 2021 19:42:12 +0000
> Description: Debs for local installing
> Label: local debs
> Origin: local debs
> Suite: oldstable
>
> And I have a pin (which I've failed to update since bullseye became
> stable hence the a=stable)
>
> Package: *
> Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
> Pin-Priority: 900
P >= 1000
causes a version to be installed even if this
constitutes a downgrade of the package
990 <= P < 1000
causes a version to be installed even if it does not
come from the target release, unless the installed version is
more recent
500 <= P < 990
causes a version to be installed unless there is a
version available belonging to the target release or the
installed version is more recent
100 <= P < 500
causes a version to be installed unless there is a
version available belonging to some other distribution or the
installed version is more
recent
0 < P < 100
causes a version to be installed only if there is no
installed version of the package
P < 0
prevents the version from being installed
> What I want this to do is hold any package in my local repository even
> if a newer version is present in debian. My local repository has patched
> packages for various reasons - e.g.
> linphone/oldstable,now 3.12.0-3+tjw10r1 amd64 [installed]
> I don't even know whether the options on that Pin line are AND or ORed
> together. The example on the webpage has:
>
> Package: *
> Pin: release v=2.2*,a=stable,c=main,o=Debian,l=Debian
> Pin-Priority: 1001
>
> When debian went from v2.2 potato to v3 woody, would this pin stop
> working? Because woody would be stable and potato oldstable at that
> point.
whereas "woody" does not".
> I'm trying to solve a (minor) problem I'm having during upgrades from
> buster to bullseye where I've backported make from bullseye to buster.
> So on my buster systems I have:
> make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed]
>
> while once I've upgraded to bullseye I want to "downgrade" from my
> backported package to make 4.3-4.1 and then continue to track bullseye.
I don't recommend this, but you get to keep all the pieces.
-dsr-
Tim Woodall
Nov 27, 2021, 2:10:04 PM11/27/21
to
On Sat, 27 Nov 2021, Dan Ritter wrote:
> Tim Woodall wrote:
>> Can anyone tell me exactly what this Pin line I have actually does - or
>> even better point me to a webpage that has more than "if you want to do
>> this use this" type of example?
>>
>> (FTAOD I know that this isn't right and is inconsistent but before I
>> start changing it I want to really understand what it's currently doing)
>>
>> I have a local repository:
>>
>> Codename: buster
>> Components: main
>> Date: Thu, 25 Nov 2021 19:42:12 +0000
>> Description: Debs for local installing
>> Label: local debs
>> Origin: local debs
>> Suite: oldstable
>>
>> And I have a pin (which I've failed to update since bullseye became
>> stable hence the a=stable)
>>
>> Package: *
>> Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
>> Pin-Priority: 900
>
> man apt_preferences # go ahead and read it, it's well-organized
>
Many thanks. I think I've been lucky and stumbled into something that
> Tim Woodall wrote:
>> Can anyone tell me exactly what this Pin line I have actually does - or
>> even better point me to a webpage that has more than "if you want to do
>> this use this" type of example?
>>
>> (FTAOD I know that this isn't right and is inconsistent but before I
>> start changing it I want to really understand what it's currently doing)
>>
>> I have a local repository:
>>
>> Codename: buster
>> Components: main
>> Date: Thu, 25 Nov 2021 19:42:12 +0000
>> Description: Debs for local installing
>> Label: local debs
>> Origin: local debs
>> Suite: oldstable
>>
>> And I have a pin (which I've failed to update since bullseye became
>> stable hence the a=stable)
>>
>> Package: *
>> Pin: release o=local debs,a=stable,n=buster,l=local debs,c=main,b=amd64
>> Pin-Priority: 900
>
> man apt_preferences # go ahead and read it, it's well-organized
>
worked for me but isn't very robust.
I've never set a default release, I've never added (except for sources)
sources.list entries other than for things I've wanted installed. So the
900 worked.
Need to think about whether I want to change that - I cannot immediately
see how it improves things for me but it might make sense to change if
that's what everybody else does. It will undoubtedly cause me
head-scratching when I upgrade to Trixy and it doesn't work...
>> I'm trying to solve a (minor) problem I'm having during upgrades from
>> buster to bullseye where I've backported make from bullseye to buster.
>> So on my buster systems I have:
>> make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed]
>>
>> while once I've upgraded to bullseye I want to "downgrade" from my
>> backported package to make 4.3-4.1 and then continue to track bullseye.
>
> You will need a priority over 1000.
>
> I don't recommend this, but you get to keep all the pieces.
>
origin "" to -100 might work - not sure if that will uninstall or
downgrade (I'll experiment). I think adding explicit pins to my
'bullseye-local-sources' package for these packages I want to downgrade
might be my only option. For the two packages I have that I want to
downgrade during the update to bullseye it's easy enough to manually fix
and I haven't yet had to backport anything to bullseye that won't keep a
patched version during the upgrade to Trixy.
Thanks for the pointers.
Tim.
David Wright
Nov 28, 2021, 12:10:05 AM11/28/21
to
like 5:, to give your package priority over newer versions.
This is standard practice for self-compiled kernels, because
newer versions are being released all the time.
Should you chance upon https://wiki.debian.org/Teams/Dpkg/FAQ,
note that those exhortations apply to packages being placed
into shared repositories, not to personal usage like yours.
> > > When debian went from v2.2 potato to v3 woody, would this pin stop
> > > working? Because woody would be stable and potato oldstable at that
> > > point.
whole versioning system. BTW I can't recall seeing an official Debian
epoch as high as 2: though someone will probably correct me.
Cheers,
David.
Tim Woodall
Nov 28, 2021, 2:20:06 AM11/28/21
to
On Sat, 27 Nov 2021, David Wright wrote:
> On Sat 27 Nov 2021 at 19:07:14 (+0000), Tim Woodall wrote:
>>
>> Yes, I don't think I can do this with a generic pin. Maybe pinning
>> origin "" to -100 might work - not sure if that will uninstall or
>> downgrade (I'll experiment). I think adding explicit pins to my
>> 'bullseye-local-sources' package for these packages I want to downgrade
>> might be my only option. For the two packages I have that I want to
>> downgrade during the update to bullseye it's easy enough to manually fix
>> and I haven't yet had to backport anything to bullseye that won't keep a
>> patched version during the upgrade to Trixy.
>>
>> Thanks for the pointers.
>
> The obvious way to do this would seem to be using an epoch,
> like 5:, to give your package priority over newer versions.
> This is standard practice for self-compiled kernels, because
> newer versions are being released all the time.
>
I can see how epochs work when you never want to return to mainline - my
> On Sat 27 Nov 2021 at 19:07:14 (+0000), Tim Woodall wrote:
>>
>> Yes, I don't think I can do this with a generic pin. Maybe pinning
>> origin "" to -100 might work - not sure if that will uninstall or
>> downgrade (I'll experiment). I think adding explicit pins to my
>> 'bullseye-local-sources' package for these packages I want to downgrade
>> might be my only option. For the two packages I have that I want to
>> downgrade during the update to bullseye it's easy enough to manually fix
>> and I haven't yet had to backport anything to bullseye that won't keep a
>> patched version during the upgrade to Trixy.
>>
>> Thanks for the pointers.
>
> The obvious way to do this would seem to be using an epoch,
> like 5:, to give your package priority over newer versions.
> This is standard practice for self-compiled kernels, because
> newer versions are being released all the time.
>
squid packages would be an example (unless debian decides to adopt my
configuration options) but they'd make less sense for things like make
and dump where I've backported and want to return to mainline once the
new version goes to stable.
My system for tracking the upstream version and patching it is
semi-automatic (unless any patch fails to apply) and I think trying to
bump epochs would add another place where the automatic process would
fail.
I do use debmultimedia.org and I find the epoch bump annoying because I
can't, for example, drop dmo during the upgrade from buster to bullseye
and (mostly) have it disappear. IIRC I added dmo years ago for mp3
codecs - it's not needed any more but it's got it's tendrils everywhere
and removing it safely and cleanly is unnecessarily hard.
Kernels are a bit of a special case as they don't 'infect' other
packages. Even my dump was holding libreadline7 from buster.
I suppose what I really want is a 'minus epsilon' flag to dch which will
generate a changelog that had a version that tests lower than the
current version but higher than all versions that test lower than the
current version.
But I cannot see such a patch being accepted, however it is implemented,
and dealing with this once every two years problem of mine is going to
be less effort than maintaining a patched version of devscripts locally
(and dpkg and whomever else compares versions)
The following pin rule appears to fix my problem - I'm not sure yet if
it's wise...
Package: make dump
Pin: release n=bullseye
Pin-Priority: 1001
Tim
The Wanderer
Nov 28, 2021, 6:20:12 AM11/28/21
to
On 2021-11-28 at 00:03, David Wright wrote:
> Epochs are unaffected by any such considerations: they override the
> whole versioning system. BTW I can't recall seeing an official Debian
> epoch as high as 2: though someone will probably correct me.
Oh, it certainly happens. Even just on my own system, I see 184 epochs
> Epochs are unaffected by any such considerations: they override the
> whole versioning system. BTW I can't recall seeing an official Debian
> epoch as high as 2: though someone will probably correct me.
of 2 or higher:
$ dpkg -l "*" | grep "\b[2-9]:[0-9]" | wc -l
184
and even one set of packages with an epoch as high as 9:
~$ dpkg -l "*" | grep "\b9:[0-9]"
ii cdrkit-doc
9:1.1.11-3.2 all Documentation for
the cdrkit package suite
ii genisoimage
9:1.1.11-3.2 amd64 Creates ISO-9660
CD-ROM filesystem images
ii wodim
9:1.1.11-3.2 amd64 command line CD/DVD
writing tool
though I don't see any of 10 or above.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Thomas Schmitt
Nov 28, 2021, 10:00:05 AM11/28/21
to
Hi,
The Wanderer wrote:
> an epoch as high as 9:
> ii wodim
> 9:1.1.11-3.2
Looks like interesting history.
https://tracker.debian.org/media/packages/c/cdrkit/changelog-91.1.11-3.2
(when read backwards) shows repeated occasions of what
https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
describes as:
"Note that the purpose of epochs is [...] to allow us to leave behind
serious mistakes."
It began in the old cdrecord days obviously to override the peculiar
upstream version numbering of cdrecord pre-releases:
-- Christian Schwarz <sch...@debian.org> Tue, 16 Sep 1997 22:16:57 +0200
cdrecord (1.5a5-1) experimental; urgency=low
...
-- Christian Schwarz <sch...@debian.org> Sun, 12 Oct 1997 21:59:11 +0200
cdrecord (1:1.5-1) unstable; urgency=low
...
* Included epoch in version number.
...
There might have been the intention to stay with a version format where
chronological sequence and dpkg sorting are in sync. But then a new
package maintainer took over and the letters got re-introduced.
This became a sorting problem later:
-- Erik Andersen <ande...@debian.org> Sat, 22 Jan 2000 12:40:27 -0700
cdrecord (1:1.8a40r3-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Mon, 21 Feb 2000 22:29:39 -0700
cdrecord (2:1.8a40-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Tue, 29 Feb 2000 10:02:15 -0700
cdrecord (3:1.8-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Sat, 29 Sep 2001 15:41:11 -0600
cdrtools (4:1.10-1) unstable; urgency=low
For a while, the pre-release suffixes were avoided and the "source" version
staid with the youngest release.
When they came back, a "+" was inserted between the minor version number of
the youngest released version and the current pre-release version:
-- Eduard Bloch <bl...@debian.org> Fri, 6 Sep 2002 20:09:15 +0200
cdrtools (4:1.10+11a31-1) unstable; urgency=low
The lower sorting rank of '+' in comparison to '-' solved the problem with
the pre-release suffixes.
Then came the big fork of cdrtools into cdrkit with new version numbers
(and an even better separator for "pre1"):
-- Eduard Bloch <bl...@debian.org> Mon, 4 Sep 2006 01:24:22 +0200
cdrkit (5:1.0~pre1-1) unstable; urgency=low
This could have been the epoch to be used up to today. But then Knoppix
was caught with having installed a cdrecord package with epoch 8.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399995#32
So the current epoch became 9.
-- Eduard Bloch <bl...@debian.org> Sat, 30 Dec 2006 16:45:31 +0100
cdrkit (9:1.1.0-1) unstable; urgency=low
The Wanderer wrote:
> I don't see any of 10 or above.
None to be expected from cdrkit. The lack of further substantial
development quite surely ended this dramedy.
(I doubt that its final maintainer would be willing to change its
epoch just to please people who installed a non-Debian package of it.)
Have a nice day :)
Thomas
The Wanderer wrote:
> an epoch as high as 9:
> 9:1.1.11-3.2
Looks like interesting history.
https://tracker.debian.org/media/packages/c/cdrkit/changelog-91.1.11-3.2
(when read backwards) shows repeated occasions of what
https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
describes as:
"Note that the purpose of epochs is [...] to allow us to leave behind
serious mistakes."
It began in the old cdrecord days obviously to override the peculiar
upstream version numbering of cdrecord pre-releases:
-- Christian Schwarz <sch...@debian.org> Tue, 16 Sep 1997 22:16:57 +0200
cdrecord (1.5a5-1) experimental; urgency=low
...
-- Christian Schwarz <sch...@debian.org> Sun, 12 Oct 1997 21:59:11 +0200
cdrecord (1:1.5-1) unstable; urgency=low
...
* Included epoch in version number.
...
There might have been the intention to stay with a version format where
chronological sequence and dpkg sorting are in sync. But then a new
package maintainer took over and the letters got re-introduced.
This became a sorting problem later:
-- Erik Andersen <ande...@debian.org> Sat, 22 Jan 2000 12:40:27 -0700
cdrecord (1:1.8a40r3-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Mon, 21 Feb 2000 22:29:39 -0700
cdrecord (2:1.8a40-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Tue, 29 Feb 2000 10:02:15 -0700
cdrecord (3:1.8-1) frozen unstable; urgency=low
...
-- Erik Andersen <ande...@debian.org> Sat, 29 Sep 2001 15:41:11 -0600
cdrtools (4:1.10-1) unstable; urgency=low
For a while, the pre-release suffixes were avoided and the "source" version
staid with the youngest release.
When they came back, a "+" was inserted between the minor version number of
the youngest released version and the current pre-release version:
-- Eduard Bloch <bl...@debian.org> Fri, 6 Sep 2002 20:09:15 +0200
cdrtools (4:1.10+11a31-1) unstable; urgency=low
The lower sorting rank of '+' in comparison to '-' solved the problem with
the pre-release suffixes.
Then came the big fork of cdrtools into cdrkit with new version numbers
(and an even better separator for "pre1"):
-- Eduard Bloch <bl...@debian.org> Mon, 4 Sep 2006 01:24:22 +0200
cdrkit (5:1.0~pre1-1) unstable; urgency=low
This could have been the epoch to be used up to today. But then Knoppix
was caught with having installed a cdrecord package with epoch 8.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399995#32
So the current epoch became 9.
-- Eduard Bloch <bl...@debian.org> Sat, 30 Dec 2006 16:45:31 +0100
cdrkit (9:1.1.0-1) unstable; urgency=low
The Wanderer wrote:
> I don't see any of 10 or above.
development quite surely ended this dramedy.
(I doubt that its final maintainer would be willing to change its
epoch just to please people who installed a non-Debian package of it.)
Have a nice day :)
Thomas
David Wright
Nov 29, 2021, 12:00:05 AM11/29/21
to
On Sun 28 Nov 2021 at 07:13:09 (+0000), Tim Woodall wrote:
> On Sat, 27 Nov 2021, David Wright wrote:
> > On Sat 27 Nov 2021 at 19:07:14 (+0000), Tim Woodall wrote:
> > >
> > > Yes, I don't think I can do this with a generic pin. Maybe pinning
> > > origin "" to -100 might work - not sure if that will uninstall or
> > > downgrade (I'll experiment). I think adding explicit pins to my
> > > 'bullseye-local-sources' package for these packages I want to downgrade
> > > might be my only option. For the two packages I have that I want to
> > > downgrade during the update to bullseye it's easy enough to manually fix
> > > and I haven't yet had to backport anything to bullseye that won't keep a
> > > patched version during the upgrade to Trixy.
> > >
> > > Thanks for the pointers.
> >
> > The obvious way to do this would seem to be using an epoch,
> > like 5:, to give your package priority over newer versions.
> > This is standard practice for self-compiled kernels, because
> > newer versions are being released all the time.
>
> I can see how epochs work when you never want to return to mainline - my
> squid packages would be an example (unless debian decides to adopt my
> configuration options) but they'd make less sense for things like make
> and dump where I've backported and want to return to mainline once the
> new version goes to stable.
I don't see why. To return to mainline, have you tried using the
> On Sat, 27 Nov 2021, David Wright wrote:
> > On Sat 27 Nov 2021 at 19:07:14 (+0000), Tim Woodall wrote:
> > >
> > > Yes, I don't think I can do this with a generic pin. Maybe pinning
> > > origin "" to -100 might work - not sure if that will uninstall or
> > > downgrade (I'll experiment). I think adding explicit pins to my
> > > 'bullseye-local-sources' package for these packages I want to downgrade
> > > might be my only option. For the two packages I have that I want to
> > > downgrade during the update to bullseye it's easy enough to manually fix
> > > and I haven't yet had to backport anything to bullseye that won't keep a
> > > patched version during the upgrade to Trixy.
> > >
> > > Thanks for the pointers.
> >
> > The obvious way to do this would seem to be using an epoch,
> > like 5:, to give your package priority over newer versions.
> > This is standard practice for self-compiled kernels, because
> > newer versions are being released all the time.
>
> I can see how epochs work when you never want to return to mainline - my
> squid packages would be an example (unless debian decides to adopt my
> configuration options) but they'd make less sense for things like make
> and dump where I've backported and want to return to mainline once the
> new version goes to stable.
syntax install myOldPackage- newMainlinePackage+ which should
move from one version to another without screwing up the dependencies.
> My system for tracking the upstream version and patching it is
> semi-automatic (unless any patch fails to apply) and I think trying to
> bump epochs would add another place where the automatic process would
> fail.
that of the Debian versions. None of the three packages you've
mentioned so far (linphone make dump) has an epoch in buster or
bullseye.
> I do use debmultimedia.org and I find the epoch bump annoying because I
> can't, for example, drop dmo during the upgrade from buster to bullseye
> and (mostly) have it disappear. IIRC I added dmo years ago for mp3
> codecs - it's not needed any more but it's got it's tendrils everywhere
> and removing it safely and cleanly is unnecessarily hard.
significantly, and any reason for hanging onto dmo evaporated.
I certainly didn't accomplish it through any clever use of versioning,
but instead using dpkg-query to list package origins, and then dry-run
removals to see which Debian packages needed installing as the dmo
ones were removed.
> I suppose what I really want is a 'minus epsilon' flag to dch which will
> generate a changelog that had a version that tests lower than the
> current version but higher than all versions that test lower than the
> current version.
under the circumstances. It could be your current version, or the
Debian version it was patched from, or the most recent Debian version,
or some version about to be superceded by a new release (to name but four).
> But I cannot see such a patch being accepted, however it is implemented,
> and dealing with this once every two years problem of mine is going to
> be less effort than maintaining a patched version of devscripts locally
> (and dpkg and whomever else compares versions)
Debian ver. Task Your ver. Installed (highest) ver.
1.0 1.0
1.0 ⮧ 1.0
1.0 patch 1.0
1.0 ⮡ 5:1.0 5:1.0
2.0 5:1.0
2.0 ⮧ 5:1.0
2.0 patch 5:1.0
2.0 ⮡ 5:2.0 5:2.0
3.0 5:2.0
IOW you patch a new version to your specifications at leisure,
and it will be automatically installed when made available.
New Debian releases will be ignored while they are unpatched.
If you track the Debian column, and an automatic patch is applied
successfully and made available, then the process could be self-
sustaining.
As I don't understand "current", I'm not sure what your -epsilon
is for. Likewise, I don't understand whether "return to mainline"
means abandon your versions, or just revisit, say, 3.0 above to
use your automated patch or come up with a new one.
> The following pin rule appears to fix my problem - I'm not sure yet if
> it's wise...
>
> Package: make dump
> Pin: release n=bullseye
> Pin-Priority: 1001
> Kernels are a bit of a special case as they don't 'infect' other
> packages. Even my dump was holding libreadline7 from buster.
a multiplicity of dependencies whether it's being held by a Pin
or by an Epoch: it's still being Held, as are its dependencies.
My experience was with kernels merely because at the time, and with
the hardware I had, building them was almost essential, quite
different from the present day. And it was robust against accidental
upgrading when I was on leave and someone else was maintaining
the system.
Cheers,
David.
Tim Woodall
Nov 29, 2021, 11:10:05 AM11/29/21
to
On Sun, 28 Nov 2021, David Wright wrote:
>
> I envisaged that what you wanted was:
>
> Debian ver. Task Your ver. Installed (highest) ver.
> 1.0 1.0
> 1.0 ? 1.0
>
> I envisaged that what you wanted was:
>
> Debian ver. Task Your ver. Installed (highest) ver.
> 1.0 1.0
> 1.0 patch 1.0
> 1.0 ? 5:1.0 5:1.0
> 2.0 5:1.0
> 2.0 ? 5:1.0
> 2.0 patch 5:1.0
> 2.0 ? 5:2.0 5:2.0
> 3.0 5:2.0
>
> IOW you patch a new version to your specifications at leisure,
> and it will be automatically installed when made available.
> New Debian releases will be ignored while they are unpatched.
>
> If you track the Debian column, and an automatic patch is applied
> successfully and made available, then the process could be self-
> sustaining.
>
> As I don't understand "current", I'm not sure what your -epsilon
> is for. Likewise, I don't understand whether "return to mainline"
> means abandon your versions, or just revisit, say, 3.0 above to
> use your automated patch or come up with a new one.
>
The problem comes, for example, where I've backported.
>
> IOW you patch a new version to your specifications at leisure,
> and it will be automatically installed when made available.
> New Debian releases will be ignored while they are unpatched.
>
> If you track the Debian column, and an automatic patch is applied
> successfully and made available, then the process could be self-
> sustaining.
>
> As I don't understand "current", I'm not sure what your -epsilon
> is for. Likewise, I don't understand whether "return to mainline"
> means abandon your versions, or just revisit, say, 3.0 above to
> use your automated patch or come up with a new one.
>
For make I wanted v4.3 so I built the make from bullseye on buster as
make/oldstable,now 4.3-4.1+tjw10r1 amd64 [installed,automatic]
And for dump there was a fix that was never added to buster so I have
dump/oldstable,now 0.4b46-8+tjw10r1
I've forced a downgrade apt-get install dump=0.4b46-8 which is no
problem, I just have to remember to do it. But I'd prefer to build that
feature into my local repo as/when I create these packages in the
future.
in fact dump was in more of a mess because (I think) I originally
backported from sid before I'd started my local repo, so I had different
versions on different machines. I started my local repo to avoid this
inconsistency. I'd forgotten about the patched version of dump. At least
now my buster machines are consistent.
For 'current' I was referring to the version in the head of the changelog.
The Wanderer
Nov 29, 2021, 11:30:05 AM11/29/21
to
I think this looks like exactly the sort of scenario which '~' is
intended for.
$ dpkg --compare-versions 0.4b46-8+tjw10r1 lt 0.4b46-8 && echo "0.4b46-8
is newer" || echo "0.4b46-8 is not newer"
0.4b46-8 is not newer
$ dpkg --compare-versions 0.4b46-8~tjw10r1 lt 0.4b46-8 && echo "0.4b46-8
is newer" || echo "0.4b46-8 is not newer"
0.4b46-8 is newer
As I understand matters, a version "foo~" will always compare as lower
than a version "foo", and this is specifically to make it possible to do
fancy things like what you're apparently aiming for here.
That won't help you with your current set of local packages - but if you
switch to that for any ones you build in the future, it might give you a
path to the end state you're hoping for.
Tim Woodall
Nov 29, 2021, 12:40:04 PM11/29/21
to
On Mon, 29 Nov 2021, The Wanderer wrote:
>
> Is there a reason you're using '+' as your separator?
>
Yes - because, for example, squid I'm building with extra settings so I
>
> Is there a reason you're using '+' as your separator?
>
want my version to be higher than the corresponding buster/bullseye
version. There is no backporting involved.
> I think this looks like exactly the sort of scenario which '~' is
> intended for.
>
and want return to mainline eventually it sounds like what I should be
doing for backported packages.
> $ dpkg --compare-versions 0.4b46-8+tjw10r1 lt 0.4b46-8 && echo "0.4b46-8
> is newer" || echo "0.4b46-8 is not newer"
> 0.4b46-8 is not newer
>
> $ dpkg --compare-versions 0.4b46-8~tjw10r1 lt 0.4b46-8 && echo "0.4b46-8
> is newer" || echo "0.4b46-8 is not newer"
> 0.4b46-8 is newer
>
> As I understand matters, a version "foo~" will always compare as lower
> than a version "foo", and this is specifically to make it possible to do
> fancy things like what you're apparently aiming for here.
>
> That won't help you with your current set of local packages - but if you
> switch to that for any ones you build in the future, it might give you a
> path to the end state you're hoping for.
>
>
can choose ~ or + depending on whether I'm backporting a higher version
from a future release or patching the current release.
I already have config for $source_distribution and $target_distribution
so I might be able to automate the patch version.
Thats the bit of magic I needed. Thanks!
David Wright
Nov 29, 2021, 11:50:05 PM11/29/21
to
On Mon 29 Nov 2021 at 17:33:35 (+0000), Tim Woodall wrote:
> On Mon, 29 Nov 2021, The Wanderer wrote:
> >
> > Is there a reason you're using '+' as your separator?
> >
> Yes - because, for example, squid I'm building with extra settings so I
> want my version to be higher than the corresponding buster/bullseye
> version. There is no backporting involved.
>
> > I think this looks like exactly the sort of scenario which '~' is
> > intended for.
> >
> But I didn't know ~ was different. Indeed, for packages I've backported
> and want return to mainline eventually it sounds like what I should be
> doing for backported packages.
[ … ]
> On Mon, 29 Nov 2021, The Wanderer wrote:
> >
> > Is there a reason you're using '+' as your separator?
> >
> Yes - because, for example, squid I'm building with extra settings so I
> want my version to be higher than the corresponding buster/bullseye
> version. There is no backporting involved.
>
> > I think this looks like exactly the sort of scenario which '~' is
> > intended for.
> >
> But I didn't know ~ was different. Indeed, for packages I've backported
> and want return to mainline eventually it sounds like what I should be
> doing for backported packages.
> Indeed, sounds perfect. Thank you. I'll have to rework my scripts so I
> can choose ~ or + depending on whether I'm backporting a higher version
> from a future release or patching the current release.
>
> I already have config for $source_distribution and $target_distribution
> so I might be able to automate the patch version.
>
> Thats the bit of magic I needed. Thanks!
any other versions entering the repositories: apt will try to upgrade
them as soon as a higher version number is seen.
You originally wrote "What I want this to do is hold any package in my
local repository even if a newer version is present in debian" and
"Were a new buster build to happen ([ … ]) I'd want my local version
to stay until I patch the new version" which appears to contradict
the above.
My epoch: method was in answer to your original post, and not the
discussion of pinning and upstream-version-debian-revisions that
has followed. I illustrated what epochs can do, and I'll leave it
at that, because it's unsuitable for what you now appear to need.
Cheers,
David.
Andrei POPESCU
Dec 5, 2021, 10:30:06 AM12/5/21
to
On Sb, 27 nov 21, 10:57:37, Tim Woodall wrote:
>
> Also, I don't know if this pin is working with a=stable or it's actually
> not doing anything useful any more. I cannot find anything that tells me
> how the Pin: line actually matches.
For diagnosing pinning `apt policy` (with or without <package>,
>
> Also, I don't know if this pin is working with a=stable or it's actually
> not doing anything useful any more. I cannot find anything that tells me
> how the Pin: line actually matches.
depending on what you're looking for) is very useful.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
0 new messages