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