Following up the conversation in #d-release...

Looking at some released versions of /usr/bin/check-support-status:

- buster (10.13, 1:10+2022.08.23) has DEB_NEXT_VER_ID=11

- bullseye (11.6, 1:11+2022.08.23) has DEB_NEXT_VER_ID=11=11

- bookworm (to be 12.0, 1:12+2023.03.17) has DEB_NEXT_VER_ID=12

Looking at older releases (prior to the change in versioning scheme) is a bit harder; the value of DEB_NEXT_VER_ID also seems to increment several times during the life of a release, which perhaps muddies the analysis. Backporting the entire package and incrementing that number during the life of the release would also be why this has not been seen in the past, I guess.

Based on the comment "# Version ID for next Debian stable", my assumption is that this should be the version number of the release that follows the stable release in which d-s-s is found. That is to say, the comment and code makes it look like DEB_NEXT_VER_ID=12 would have been right for bullseye and DEB_NEXT_VER_ID=13 would be right for bookworm.

Incrementing to DEB_NEXT_VER_ID=12 in the next bullseye point release seems reasonable to me; also incrementing in bookworm to DEB_NEXT_VER_ID=13 would be logical.

Rather than having base-files predepend on d-s-s, I suspect apt could be convinced to upgrade them in the right order by having base-files conflict (or perhaps break?) the 1:11+2022.08.23 version of d-s-s, with a fixed version in bullseye or the upgraded version in bookworm both being OK.

I haven't looked at the code paths to check if this warning is 'only' cosmetic or if it also causes d-s-s to stop working.

regards
Stuart



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/       stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Reply via email to