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