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. 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. 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? * How to achieve such differentiation in a way that does not require overruling DPL delegates? I see that Luca rejected my diversion-based suggestion, but I note that it does not require release-team cooperation and does not negatively impact autopkgtests for testing migration. Helmut
