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.
