Re: Apt pinning.
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
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.
You don't bump epochs; you merely make sure that your epoch exceeds
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.
I remember removing dmo when the mainstream Debian packages improved
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.
s/current/particular/; because "current" is not a defined concept
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)
I envisaged that what you wanted was:
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
I can't comment on that, and I notice that Dan couldn't recommend it.
> Kernels are a bit of a special case as they don't 'infect' other
> packages. Even my dump was holding libreadline7 from buster.
True, but I don't see what difference it makes to a package with
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.
Reply to: