On Mon, 5 Aug 2024 at 08:42, Helmut Grohne <hel...@subdivi.de> wrote: > > Hi Gioele, > > On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote: > > as the maintainer (and upstream author) of the current lsb_release > > implementation used in Debian and derivatives (src:lsb-release-minimal), I'd > > like to voice my support in favor of having enough information in > > /usr/lib/os-release to be able to tell "testing" and "unstable" apart. > > thanks for speaking up. > > > Couldn't the CTTE just rule on the question: > > > > * should Debian provide a way to distinguish between the two > > similar-but-not-identical, rolling, ephemeral releases called "testing" > > and "staging" via /etc/os-release? > > > > and leave the details of how to implement that decision (dependencies, > > Essential:ye, uploads, releases, etc...) to the involved parties? > > My understanding of the constitution is that this is not something we > can rule. Consider 6.3.5: > > | The Technical Committee restricts itself to choosing from or adopting > compromises between solutions and decisions which have been proposed and > reasonably thoroughly discussed elsewhere. > > Leaving these details out of scope of the decision would further > entrench the conflict as it would be unclear how the responsibility of > the os-release metadata would be transitioned and I would expect further > disagreement on that aspect. > > The primary method proposed by Luca intends to leverage t-p-u, which has > been nacked by two release team members. As such selecting that option > would imply overruling DPL delegates, which also is not a power of the > CTTE.
Maybe I'm too optimistic, but again in my reading I do not see vetoes, I see valid concerns that I believe I responded to. I believe Gioele's proposal that I adopted meets these criterias: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u Again, if those criterias are incomplete, then I'd ask that documentation be brought up to date, as this is a generic mechanism, and having everything needed to use it documented is beneficial for the project at large, outside of this one instance. > As I see it, we need a detailed proposal on how you would see this > implemented in order to positively rule on this matter. The level of > detail is debatable, but due to how it affects the essential system I > recommend doing a PoC-level at least. > > Beyond all of this, more recent posts to this thread have made it more > clear to me that the state of /etc/os-release maybe should not only > depend on the suite you pass to debootstrap, but represent an > administrative choice (with a useful default). For instance, I tend to > install laptops as unstable (in order to pick up reasonable hardware > support) and eventually transition them to oldstable (when I plan to > decommission the system after oldstable ends support). It would not be > useful to have these labeled as unstable for the entirety of their use. Such laptop's os-release would say sid when it's running sid and then say <oldstable codename> when it runs oldstable, so I don't see a problem there? > In order to move this request forward, I see two questions that would > benefit from answers: > * What kind of code behaves differently for testing and unstable beyond > presenting a different string to a user? That's very hard to answer. Right now anybody who looks at testing vs unstable will necessarily ignore os-release, as it doesn't help, and on top of that the addition of VERSION_CODENAME to sid is relatively recent, so in theory nothing should change? But not sure how one could answer that question authoritatively, short of actually uploading and see what happens.
