Re: Apt pinning.
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
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.
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.
Reply to: