On Thu, 1 Aug 2024 at 18:33, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > There are several different ways of having different content in sid vs > > testing, and some have been proposed in the latest bug linked above, I > > would be happy to discuss those details too if required. > > Generally the technical committee works best if it can consider a concrete > technical proposal for a fix alongside the problem statement. I'm not a > member, but as an interested bystander, I would like to see the details of > precisely how you would implement your desired functionality. That could > be several options if you'd like the committee to choose between them.
I was about to say that the proposal is in the linked bug, but it has disappeared - it could be due to the bugs getting unlinked. Anyway, my variant is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54 There was also a slight variant by Gioele, that again I fail to find now and it might be because of the bugs being rearranged, where testing-proposed-updates is used to upload testing-specific content. The TL;DR: ensure that the version of the 'os-release' package with the content for unstable stays in unstable and never migrates, and the version of the 'os-release' package with the content for testing goes to testing either via a quick migration or via testing-proposed-updates. And the exact details on _how_ to manage it are all up for discussion of course, if there are better ideas I'm happy to implement them. The reason for escalating to the CTTE is not the implementation details however, it's a core conflict about the basic concept of os-release itself. > I'd also like to see an elaboration of how you propose to distinguish sid > from testing. This would be an ill-defined concept on the systems that I > personally install testing packages on, and the specific criteria that you > would use is not obvious to me from the bug discussion. If you 'debootstrap unstable /tmp/a' and then 'cat /tmp/a/usr/lib/os-release' you will see: PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" VERSION_CODENAME=sid ID=debian If you instead 'debootstrap testing /tmp/b' and then 'cat /tmt/b/lusr/lib/os-release' you will see: PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie RELEASE_TYPE=pre-release ID=debian That's it. Of course if what you are saying is that you mix and match a selection of packages from testing and unstable, well that's a frankendebian - you can do that on any release (I have some testing packages pulled in my debian stable laptop right now). So the identification will be as it is right now, it will depend on the version of the package providing the os-release file, which like any other package can be manually overridden, upgraded, downgraded if one really wishes to do so. I could echo "ID=windows 3.1" into my local /etc/os-release and nothing would stop me or fix it until the next stable release. But this doesn't really change the purpose or meaning of the os-release specification and its implementation and purpose. > I did review the discussion #1021663 in the hope that I would find a > detailed technical proposal there, but your messages to that bug seemed to > focus on criticisms of the current behavior mixed with insults. I wasn't > able to find a proposal, but it's entirely possible I missed it. There are for sure a lot of criticisms of the bugs in base-files, but there are no insults.
