Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Wed, 7 Aug 2024 at 07:54, Sean Whitton  wrote:
>
> Hello,
>
> On Tue 06 Aug 2024 at 11:45pm +01, Luca Boccassi wrote:
>
> > It's just a bunch of emails. I have no idea where that is coming from,
> > because it's certainly not the intention. Your guess about languages
> > is probably accurate.
>
> Your use of English suggests to me you have native or near-native
> fluency, and you said upthread that you live in an English-speaking
> country and see yourself as culturally fitting-in.
> Therefore, I would ask you to think carefully about whether the problem
> may be more subtle than just misunderstandings of English tone.

And I would ask you to understand that your statements about processes
have misled me into changing this proposal in a way that was against
my interest as petitioner. An unfortunate and unintentional
misunderstanding with no ill intent behind it I'm sure, but it still
happened. Naively, this would appear much more problematic to me than
some perceived misunderstandings about unspecified and nebulous
"English tone" (?) in a bunch of emails, but most likely being the
aggrieved party has something to do with it.

A brief summary:

Here you said that you could rule on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368
Here I reply asking you to please do so if it is possible, changing
the proposal to be on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#388
Here you respond to my request by calling a vote to dismiss the
proposal because you don't rule on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#433

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

On Tue 06 Aug 2024 at 11:45pm +01, Luca Boccassi wrote:

> It's just a bunch of emails. I have no idea where that is coming from,
> because it's certainly not the intention. Your guess about languages
> is probably accurate.

Your use of English suggests to me you have native or near-native
fluency, and you said upthread that you live in an English-speaking
country and see yourself as culturally fitting-in.
Therefore, I would ask you to think carefully about whether the problem
may be more subtle than just misunderstandings of English tone.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

On Tue 06 Aug 2024 at 05:42pm +02, Helmut Grohne wrote:

> I kindly ask you to stop posting to this bug and mailing list for at
> least 24h from now. Multiple participants have asked you to improve the
> way you interact. I am not seeing such improvement and remind you of the
> Debian Code of Conduct available at
> https://www.debian.org/code_of_conduct. The way you replied to Wouter is
> not respectful and it is not appropriate here. Please distance yourself
> from this matter for a day and reflect.

I'd go further and ask Luca to stop posting until we've concluded our
vote, unless that takes the full week.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 20:53, Marc Haber  wrote:
>
> Hi,
>
> I am in favor of your request.
>
> On Tue, Aug 06, 2024 at 05:28:57PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 16:43, Helmut Grohne  wrote:
> > > I kindly ask you to stop posting to this bug and mailing list for at
> > > least 24h from now. Multiple participants have asked you to improve the
> > > way you interact. I am not seeing such improvement and remind you of the
> > > Debian Code of Conduct available at
> > > https://www.debian.org/code_of_conduct. The way you replied to Wouter is
> > > not respectful and it is not appropriate here. Please distance yourself
> > > from this matter for a day and reflect.
> >
> > Please stop trying to conflate highlighting factual inaccuracies with
> > "disrespect". There is nothing inappropriate in replying "B is
> > happening" to "A is happening", when it's B and not A that is
> > happening.
>
> The problem is not WHAT you are saying, it is HOW you are saying it. In
> those discussions (and you are part of a lot of such discussions) you
> sound to the casual reader as if you're talking down to somebody you
> consider a moron, unable to pull up their own pants in the morning. This
> might be a cultural or language issue because English is a foreign
> language for both of us, so I am just trying to say how your messages
> sound for me.

It's just a bunch of emails. I have no idea where that is coming from,
because it's certainly not the intention. Your guess about languages
is probably accurate.

Bug#1077764: Ruling request on os-release specification implementation

[Gioele Barabucci]

On Tue, 6 Aug 2024 17:55:23 +0200 Wouter Verhelst  wrote:

- Gioele's message is about reimplementing lsb_release in terms of
  os-release.


Not really. lsb_release has already been reimplemented purely in terms 
of os-release since bookworm. Even the older Python version used 
os-release as the main source of truth, if available.



Surely the reason that os-release exists is not "so
  we have a way to implement the lsb_release script".


Not "the" reason, but one of the reasons. lsb_release is explicit 
referred to in the FAQs: http://0pointer.de/blog/projects/os-release



In fact, if that
  were the only reason, then we could do away with os-release entirely,
  implement lsb_release for Debian in terms of parsing apt
  configuration, and we wouldn't even be having this discussion.


This is what I would like to highlight:

The status quo until Debian 11 was that users of Debian were be able to 
_distinguish_ between "testing" and "unstable". [1]


That ability was however provided by lsb_release instead of base-files.

This ability of lsb_release to tell "testing" apart from "unstable" 
(often with wrong results, see the amount of bug reports) was used by 
many users and applications. (And I know because of the bug reports I 
received once lsb_release started being Provided by 
src:lsb-release-minimal).


My opinion is that lsb_release should not be in the business of guessing 
if a OS is "testing" or "unstable". Self-identification is a task of the 
OS itself.


Another opinion of mine is that LSB and lsb_release are legacy 
interfaces not suited for the modern world. This is also the opinion of 
Debian since Debian 9 (stretch, 2015, [2]).


So the modern place where to implement the distinction that was there 
before Debian 12, is the current cross-distro facility /usr/lib/os-release.



[1] https://bugs.debian.org/1038383#10

[2] 
, 
section 5.1.6


--
Gioele Barabucci

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

Hi,

I am in favor of your request.

On Tue, Aug 06, 2024 at 05:28:57PM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 16:43, Helmut Grohne  wrote:
> > I kindly ask you to stop posting to this bug and mailing list for at
> > least 24h from now. Multiple participants have asked you to improve the
> > way you interact. I am not seeing such improvement and remind you of the
> > Debian Code of Conduct available at
> > https://www.debian.org/code_of_conduct. The way you replied to Wouter is
> > not respectful and it is not appropriate here. Please distance yourself
> > from this matter for a day and reflect.
> 
> Please stop trying to conflate highlighting factual inaccuracies with
> "disrespect". There is nothing inappropriate in replying "B is
> happening" to "A is happening", when it's B and not A that is
> happening.

The problem is not WHAT you are saying, it is HOW you are saying it. In
those discussions (and you are part of a lot of such discussions) you
sound to the casual reader as if you're talking down to somebody you
consider a moron, unable to pull up their own pants in the morning. This
might be a cultural or language issue because English is a foreign
language for both of us, so I am just trying to say how your messages
sound for me.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 16:55, Wouter Verhelst  wrote:
>
> On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst  wrote:
> > > The question is:
> > >
> > >   what is, exactly, the problem that the os-release specification is
> > >   supposed to solve? And how does unstable and testing being
> > >   undistinguishable from each other not solve that problem?
> > >
> > > I have not seen an answer to that question, and it is, I think the
> > > central question that we need to see answered. Because that would show
> > > what the *benefit* of the os-release specification is, and that would
> > > allow the ctte to do a proper cost-benefit analysis of the proposed
> > > solutions.
> > >
> > > While I don't think this is the case, it is of course not entirely
> > > impossible that I have missed or overlooked the reply to the question I
> > > state above, in which case I apologise and would kindly ask that you
> > > point to it.
> >
> > Yes, I'm afraid you did miss it, as it has been answered multiple
> > times. Please re-read replies from myself, Gioele and Marc.
>
> - Gioele's message is about reimplementing lsb_release in terms of
>   os-release. As it wants to do largely the same thing as os-release, it
>   stands to reason that it would have the same problems, but that does
>   not actually answer the question as to what the problem is you're
>   trying to solve. Surely the reason that os-release exists is not "so
>   we have a way to implement the lsb_release script". In fact, if that
>   were the only reason, then we could do away with os-release entirely,
>   implement lsb_release for Debian in terms of parsing apt
>   configuration, and we wouldn't even be having this discussion.

It's not, though, because it's the same issue. Quoting verbatim:

"My opinion is that by deciding to not ship enough information in
/usr/lib/os-release to distinguish between testing and unstable the
CTTE is just pushing that same issue into a myriad of other packages."

https://lists.debian.org/debian-ctte/2024/08/msg00057.html

> - Marc's answer is an example involving managing the life cycle, using
>   ansible, of various hosts. While that is indeed a real-life example
>   where something like os-release could be useful, it is not an answer
>   to the question of what it is, exactly, that os-release is trying to
>   do. You do not answer a question "what is the problem that X is trying
>   to solve" by way of "here is one example of things that are easier",
>   because it is always possible to give a counter-example of things that
>   would decidedly *not* be easier -- such as managing quality in Debian
>   in light of packages that change their behavior if they detect that
>   they're on a different distribution.

Yes, the reason for pointing to that response was exactly to answer
your question about "benefits", which is something you were looking
for. What os-release is for is answered elsewhere, for starters in the
very first mail, 4th paragraph:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

And other responses such as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#208

Again, I've explained it many times through the thread, please skim it
again, as I do not really want to re-write the same things again.

> - You gave multiple instances of "people want to do this" without going
>   into detail as to why.

I have written literally walls upon walls of text, among the many
things one might say, "not enough details" is really one that I
wouldn't have expected

> This question matters, because understanding the need is the first step
> in understanding why the current situation is suboptimal.
>
> From my point of view, the need has always been the ability to identify,
> with limited detail, what a particular installation contains. I say
> "with limited detail", because it can never be complete by way of a
> single file; there will always be more details that such a file format
> cannot express. But this is sufficient for things like labelling other
> installations on the same hardware in a boot menu, remembering what you
> were trying to do with that image on the disk somewhere, or various
> other cases where a hint as to what an image is could help.

And yet because of this bug you can't even do that right now. Am I
going to boot trixie or sid in that boot menu? No idea, they have the
same label

> It can never be more than a hint, however; there is always more detail
> to be found. For instance, in the case of Debian stable, os-release does
> not tell you when the installation was last updated, what the exact way
> was in which the installation was created, or which set of third-party
> sources was added to the system to install packages from.

That's not a problem, because those are not problems that os-release
set out to solve. Answering the question "which distro and which
release is this", however, is.

> I'm sure there are people who want to

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 16:43, Helmut Grohne  wrote:
>
> Hi Luca,
>
> I kindly ask you to stop posting to this bug and mailing list for at
> least 24h from now. Multiple participants have asked you to improve the
> way you interact. I am not seeing such improvement and remind you of the
> Debian Code of Conduct available at
> https://www.debian.org/code_of_conduct. The way you replied to Wouter is
> not respectful and it is not appropriate here. Please distance yourself
> from this matter for a day and reflect.

Please stop trying to conflate highlighting factual inaccuracies with
"disrespect". There is nothing inappropriate in replying "B is
happening" to "A is happening", when it's B and not A that is
happening.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst  wrote:
> > The question is:
> >
> >   what is, exactly, the problem that the os-release specification is
> >   supposed to solve? And how does unstable and testing being
> >   undistinguishable from each other not solve that problem?
> >
> > I have not seen an answer to that question, and it is, I think the
> > central question that we need to see answered. Because that would show
> > what the *benefit* of the os-release specification is, and that would
> > allow the ctte to do a proper cost-benefit analysis of the proposed
> > solutions.
> >
> > While I don't think this is the case, it is of course not entirely
> > impossible that I have missed or overlooked the reply to the question I
> > state above, in which case I apologise and would kindly ask that you
> > point to it.
> 
> Yes, I'm afraid you did miss it, as it has been answered multiple
> times. Please re-read replies from myself, Gioele and Marc.

- Gioele's message is about reimplementing lsb_release in terms of
  os-release. As it wants to do largely the same thing as os-release, it
  stands to reason that it would have the same problems, but that does
  not actually answer the question as to what the problem is you're
  trying to solve. Surely the reason that os-release exists is not "so
  we have a way to implement the lsb_release script". In fact, if that
  were the only reason, then we could do away with os-release entirely,
  implement lsb_release for Debian in terms of parsing apt
  configuration, and we wouldn't even be having this discussion.
- Marc's answer is an example involving managing the life cycle, using
  ansible, of various hosts. While that is indeed a real-life example
  where something like os-release could be useful, it is not an answer
  to the question of what it is, exactly, that os-release is trying to
  do. You do not answer a question "what is the problem that X is trying
  to solve" by way of "here is one example of things that are easier",
  because it is always possible to give a counter-example of things that
  would decidedly *not* be easier -- such as managing quality in Debian
  in light of packages that change their behavior if they detect that
  they're on a different distribution.
- You gave multiple instances of "people want to do this" without going
  into detail as to why.

This question matters, because understanding the need is the first step
in understanding why the current situation is suboptimal.

>From my point of view, the need has always been the ability to identify,
with limited detail, what a particular installation contains. I say
"with limited detail", because it can never be complete by way of a
single file; there will always be more details that such a file format
cannot express. But this is sufficient for things like labelling other
installations on the same hardware in a boot menu, remembering what you
were trying to do with that image on the disk somewhere, or various
other cases where a hint as to what an image is could help.

It can never be more than a hint, however; there is always more detail
to be found. For instance, in the case of Debian stable, os-release does
not tell you when the installation was last updated, what the exact way
was in which the installation was created, or which set of third-party
sources was added to the system to install packages from.

I'm sure there are people who want to know this type of information
beyond what Debian is currently willing to provide, and of course they
are then required to add random hacks to their scripts to improve the
situation. Similarly, I'm sure there may also be people who would need
to know more than which suite a package was built from -- I regularly
check dpkg logs to figure out when last an installation was updated, for
instance -- and so if I want to do that automatically, then I will also
have to hack my code to improve upon that. There is really no difference
here.

The fact that Debian has two in-development suites is actually an
implementation detail of Debian, and to decide that *this* one
implementation detail of a particular installation is important enough
to be reflected in a file, but all these other implementation details of
what the image was built from are not, seems fairly arbitrary from my
point of view.

I'm sure it does not for you, but you have not explained why it is that
it is not arbitrary. Specifically, you have not explained why Debian
should *care*.

We provide an os-release file. It provides information about the
installation. The information may be wrong according to the spec, but
I don't think that's a spec that Debian has agreed in any form or shape
to implement.

If you want that to change, you should explain why it should change in
more detail than "this is what the spec says".

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixtur

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

I kindly ask you to stop posting to this bug and mailing list for at
least 24h from now. Multiple participants have asked you to improve the
way you interact. I am not seeing such improvement and remind you of the
Debian Code of Conduct available at
https://www.debian.org/code_of_conduct. The way you replied to Wouter is
not respectful and it is not appropriate here. Please distance yourself
from this matter for a day and reflect.

Thank you for considering

Helmut

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst  wrote:
>
> On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst  wrote:
> > > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > > > That would make it contradictory with itself and everything else that
> > > > uses it, so it's not a change that would be acceptable.
> > >
> > > Why not?
> >
> > Because A is A, not B.
> >
> > > You seem to hold the opinion in this discussion that the os-release
> > > specification is perfect and that Debian's implementation of it is
> > > wrong and should be corrected and there is no discussion.
> > >
> > > I'm not saying that's not true, but it does make it more difficult to
> > > understand the reasoning.
> >
> > Nobody said anything is perfect.
>
> And yet:
>
> [...]
> > You cannot argue that the math book is wrong and Debian is right to
> > say that 2+2=5.
>
> The os-release specification is not a math book. It is an
> English-language specification. Specifications like that are not math.

In this case it's very much like math. It's a simple assignment,
key=value, and it's set wrongly. The fact that it's wrong is not in
question. Whether it's acceptable or not for it to be wrong is in
question.

> It is perfectly viable to accept that certain things are difficult to do
> for one distribution, perhaps even too difficult to do, and that
> therefore it is not worth doing. But in order to make that call, it is
> necessary to know more.

Certain things may be, but this isn't one of them. This isn't
difficult, it's trivial to do, if one wanted to do it.

> > > You want to update the implementation in Debian to more closely match
> > > the specification. I and others have asked you what the benefit of this
> > > would be, but TTBOMK the answers you have given all essentially boiled
> > > down to "because that is what the standard requires", and/or "because
> > > people might want to know the difference between the two", without going
> > > into detail or providing real-world examples as to why this would be the
> > > case. I myself have even given a real-world example, but then it turned
> > > out that this was not even a good idea and Helmut Grohne showed me a
> > > better way to implement what I needed to do.
> >
> > Please see (plenty) of other mails. I know there's a lot of noise and
> > it takes time to sift through the walls of texts, but that's why I do
> > not want to add even more.
>
> Please do not mistake my disagreement for misunderstanding.
>
> I have read every mail in this thread. I have perhaps skipped over some
> parts of some emails which were going off on a tangent, but I have
> definitely read every one of *your* words in this thread. I have also
> opened the links to various other sites and bug reports that you have
> posted. In short, I *have* done my homework, thank you very much.
>
> > I added multiple examples,
>
> I have seen vague handwavy statements of "people might want to do this".
> I have seen examples where you explain how a set of commands does not
> result in the os-release file having the "correct" contents.

Then this homework would get a D- ;-) We _do_ this, already, all the
time. There's no "might", I've linked multiple cases where image
builders need to do this stuff, and Debian is uniquely a pain.

> What I have not seen is *why this matters*, despite asking multiple
> times. "Because that is what the os-release spec says" is a circular
> non-answer.

This has been answered multiple times, by multiple people even.

> The question is:
>
>   what is, exactly, the problem that the os-release specification is
>   supposed to solve? And how does unstable and testing being
>   undistinguishable from each other not solve that problem?
>
> I have not seen an answer to that question, and it is, I think the
> central question that we need to see answered. Because that would show
> what the *benefit* of the os-release specification is, and that would
> allow the ctte to do a proper cost-benefit analysis of the proposed
> solutions.
>
> While I don't think this is the case, it is of course not entirely
> impossible that I have missed or overlooked the reply to the question I
> state above, in which case I apologise and would kindly ask that you
> point to it.

Yes, I'm afraid you did miss it, as it has been answered multiple
times. Please re-read replies from myself, Gioele and Marc.

> [...]
> > > Given the what we know so far, in my opinion (for as much as that one
> > > holds merit), Debian should declare that we implement the os-release
> > > specification only from the time of the release of our distribution
> > > suites, and that the data in the os-release file before that (i.e., in
> > > our development suites) could be right or could be wrong but that we do
> > > not warrant that it is either way.
> >
> > That's not what happens right now though - the file is there, so it is
> > implemented.
>
> The file is there, but as 

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst  wrote:
> > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > > That would make it contradictory with itself and everything else that
> > > uses it, so it's not a change that would be acceptable.
> >
> > Why not?
> 
> Because A is A, not B.
> 
> > You seem to hold the opinion in this discussion that the os-release
> > specification is perfect and that Debian's implementation of it is
> > wrong and should be corrected and there is no discussion.
> >
> > I'm not saying that's not true, but it does make it more difficult to
> > understand the reasoning.
> 
> Nobody said anything is perfect.

And yet:

[...]
> You cannot argue that the math book is wrong and Debian is right to
> say that 2+2=5.

The os-release specification is not a math book. It is an
English-language specification. Specifications like that are not math.

It is perfectly viable to accept that certain things are difficult to do
for one distribution, perhaps even too difficult to do, and that
therefore it is not worth doing. But in order to make that call, it is
necessary to know more.

> > You want to update the implementation in Debian to more closely match
> > the specification. I and others have asked you what the benefit of this
> > would be, but TTBOMK the answers you have given all essentially boiled
> > down to "because that is what the standard requires", and/or "because
> > people might want to know the difference between the two", without going
> > into detail or providing real-world examples as to why this would be the
> > case. I myself have even given a real-world example, but then it turned
> > out that this was not even a good idea and Helmut Grohne showed me a
> > better way to implement what I needed to do.
> 
> Please see (plenty) of other mails. I know there's a lot of noise and
> it takes time to sift through the walls of texts, but that's why I do
> not want to add even more.

Please do not mistake my disagreement for misunderstanding.

I have read every mail in this thread. I have perhaps skipped over some
parts of some emails which were going off on a tangent, but I have
definitely read every one of *your* words in this thread. I have also
opened the links to various other sites and bug reports that you have
posted. In short, I *have* done my homework, thank you very much.

> I added multiple examples,

I have seen vague handwavy statements of "people might want to do this".
I have seen examples where you explain how a set of commands does not
result in the os-release file having the "correct" contents.

What I have not seen is *why this matters*, despite asking multiple
times. "Because that is what the os-release spec says" is a circular
non-answer.

The question is: 

  what is, exactly, the problem that the os-release specification is
  supposed to solve? And how does unstable and testing being
  undistinguishable from each other not solve that problem?

I have not seen an answer to that question, and it is, I think the
central question that we need to see answered. Because that would show
what the *benefit* of the os-release specification is, and that would
allow the ctte to do a proper cost-benefit analysis of the proposed
solutions.

While I don't think this is the case, it is of course not entirely
impossible that I have missed or overlooked the reply to the question I
state above, in which case I apologise and would kindly ask that you
point to it.

[...]
> > Given the what we know so far, in my opinion (for as much as that one
> > holds merit), Debian should declare that we implement the os-release
> > specification only from the time of the release of our distribution
> > suites, and that the data in the os-release file before that (i.e., in
> > our development suites) could be right or could be wrong but that we do
> > not warrant that it is either way.
> 
> That's not what happens right now though - the file is there, so it is
> implemented.

The file is there, but as you assert it does not implement the spec
correctly, it is not implemented correctly. So allow me to rephrase: at
this point we implement the os-release specification correctly only from
the time of release, not before, and without explanation as to why we
should, I don't think that should change.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 11:40, Matthew Vernon  wrote:
>
> On 06/08/2024 11:22, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon  wrote:
> >>
> >> Hi,
> >>
> >> On 06/08/2024 10:42, Luca Boccassi wrote:
> >>
> >>> This is not a hard technical problem with no known solution that we
> >>> are asking for design guidance on. This is a trivial technical
> >>> problem with a hard social conflict at its core. What we are really
> >>> blocked on is that the current owner of os-release refuses to let us
> >>> fix it.
> >> This is an unfair and inaccurate summary. The policy question of "should
> >> testing and unstable be differentiated by os-release" isn't
> >> straightforward, and there isn't consensus that the answer should be
> >> "yes", as you would like it to be.
> >
> > But in what way is it inaccurate?
>
> Your text says (at least as I read it) "the technical problem is easy,
> but the os-release maintainer is preventing us from implementing the
> otherwise-agreed solution". This is an accusation of poor conduct aimed
> at the os-release maintainer.

It is not? It means what it says: the technical side is trivial, but
there is a social disagreement on what the policy should be, hence the
involvement of the CTTE to solve this conflict. If there was agreement
then I wouldn't be here, no? Recognizing and expressing that there is
a policy disagreement, resulting in a change being blocked, is not an
accusation of any kind.

> > And same question as I asked Sean earlier - by "consensus" here, do
> > you mean that you want to see more people outside of TC members
> > chiming in on the policy question?
>
> No. TC bugs are not popularity contests. My point is that your paragraph
> I objected to was claiming that the os-release maintainer was stopping
> "us" [presumably meaning Debian] from fixing the bug that os-release
> does not differentiate between testing and unstable.

No, I did not mean "Debian", I meant people who want to implement this change.

Bug#1077764: Ruling request on os-release specification implementation

[Matthew Vernon]

On 06/08/2024 11:22, Luca Boccassi wrote:

On Tue, 6 Aug 2024 at 11:10, Matthew Vernon  wrote:


Hi,

On 06/08/2024 10:42, Luca Boccassi wrote:


This is not a hard technical problem with no known solution that we
are asking for design guidance on. This is a trivial technical
problem with a hard social conflict at its core. What we are really
blocked on is that the current owner of os-release refuses to let us
fix it.

This is an unfair and inaccurate summary. The policy question of "should
testing and unstable be differentiated by os-release" isn't
straightforward, and there isn't consensus that the answer should be
"yes", as you would like it to be.


But in what way is it inaccurate?


Your text says (at least as I read it) "the technical problem is easy, 
but the os-release maintainer is preventing us from implementing the 
otherwise-agreed solution". This is an accusation of poor conduct aimed 
at the os-release maintainer.


Given that there is a policy question here that is not straightforward 
(and where there isn't an obvious consensus), this isn't a fair 
accusation to make. People are allowed to disagree with each other in 
Debian, and must be allowed to do so without being accused of acting in 
bad faith.



And same question as I asked Sean earlier - by "consensus" here, do
you mean that you want to see more people outside of TC members
chiming in on the policy question? 


No. TC bugs are not popularity contests. My point is that your paragraph 
I objected to was claiming that the os-release maintainer was stopping 
"us" [presumably meaning Debian] from fixing the bug that os-release 
does not differentiate between testing and unstable.


In fact, you are trying to change Debian's position on the 
differentiation between testing and unstable; the os-release maintainer 
is acting, in effect, to maintain the current RT position. You are 
"blocked" by having not yet persuaded the necessary people (RT at least, 
maybe also the TC) that this change should happen.


To be clear: it's perfectly OK to want to change the project's position 
on this question (even though I don't currently agree with you); it's 
perfectly OK to try and persuade the os-release maintainer to do as you 
wish; it's _not_ OK to accuse the os-release maintainer of bad behaviour 
because they don't agree with you.


Regards,

Matthew

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 11:37, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Tue, Aug 06, 2024 at 10:42:28AM +0100, Luca Boccassi wrote:
> > that matters. This is not a hard technical problem with no known
> > solution that we are asking for design guidance on. This is a trivial
> > technical problem with a hard social conflict at its core. What we are
>
> That's actually great news. Many of us have perceived this as difficult
> to solve on a technical level. Would you mind attaching your
> implementation to a mail? For instance you may attach your new source
> package (possibly multiple times for different suites) as well as
> debdiffs for other related packages (if needed). I was assuming that
> asking for this was too much prior to making a decision, but as you say
> it is trivial, it is much easier to reason about that code than reason
> about what we have now.

Yes, I do mind, as explained here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#388

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

On Tue, Aug 06, 2024 at 10:42:28AM +0100, Luca Boccassi wrote:
> that matters. This is not a hard technical problem with no known
> solution that we are asking for design guidance on. This is a trivial
> technical problem with a hard social conflict at its core. What we are

That's actually great news. Many of us have perceived this as difficult
to solve on a technical level. Would you mind attaching your
implementation to a mail? For instance you may attach your new source
package (possibly multiple times for different suites) as well as
debdiffs for other related packages (if needed). I was assuming that
asking for this was too much prior to making a decision, but as you say
it is trivial, it is much easier to reason about that code than reason
about what we have now.

Helmut

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 11:26, Matthew Vernon  wrote:
>
> On 06/08/2024 11:22, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon 
> > wrote:
>
> >> The policy question of "should testing and unstable be
> >> differentiated by os-release" isn't straightforward, and there
> >> isn't consensus that the answer should be "yes", as you would like
> >> it to be.
>
> >> Debian's current (and long-standing) answer to that question is
> >> "no", and my view is that you have not advanced a sufficiently
> >> compelling case that this answer should be changed.
> >
> > Sorry, I don't follow. How is that related to the implementation
> > details of how to solve it?
>
> Well, because if the answer to the question is "no, testing and unstable
> should not be differentiated by os-release", then there is no need to
> come up with a system whereby they are differentiated.

Yes, I agree, that's what I was trying to convey, I guess I wrote it
in a confusing way

Bug#1077764: Ruling request on os-release specification implementation

[Matthew Vernon]

On 06/08/2024 11:22, Luca Boccassi wrote:

On Tue, 6 Aug 2024 at 11:10, Matthew Vernon 
wrote:



The policy question of "should testing and unstable be
differentiated by os-release" isn't straightforward, and there
isn't consensus that the answer should be "yes", as you would like
it to be.



Debian's current (and long-standing) answer to that question is
"no", and my view is that you have not advanced a sufficiently
compelling case that this answer should be changed.


Sorry, I don't follow. How is that related to the implementation 
details of how to solve it?


Well, because if the answer to the question is "no, testing and unstable 
should not be differentiated by os-release", then there is no need to 
come up with a system whereby they are differentiated.


Regards,

Matthew

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 11:10, Matthew Vernon  wrote:
>
> Hi,
>
> On 06/08/2024 10:42, Luca Boccassi wrote:
>
> > This is not a hard technical problem with no known solution that we
> > are asking for design guidance on. This is a trivial technical
> > problem with a hard social conflict at its core. What we are really
> > blocked on is that the current owner of os-release refuses to let us
> > fix it.
> This is an unfair and inaccurate summary. The policy question of "should
> testing and unstable be differentiated by os-release" isn't
> straightforward, and there isn't consensus that the answer should be
> "yes", as you would like it to be.

But in what way is it inaccurate? Are you saying there _is_ a hard
technical problem with no known solution somewhere? My point is that I
don't think there is one. I understand that the policy question is not
straightforward, but that's exactly the point I was trying to convey:
nitpicking over how a specific solution looks like is a distraction
from the policy question, which is the important part of all of this,
and the part that really needs clarification.

And same question as I asked Sean earlier - by "consensus" here, do
you mean that you want to see more people outside of TC members
chiming in on the policy question? Again, I have not publicised this
anywhere. I can do that and get more people to chime in, if that's the
request.

> Debian's current (and long-standing) answer to that question is "no",
> and my view is that you have not advanced a sufficiently compelling case
> that this answer should be changed.

Sorry, I don't follow. How is that related to the implementation
details of how to solve it?

Bug#1077764: Ruling request on os-release specification implementation

[Matthew Vernon]

Hi,

On 06/08/2024 10:42, Luca Boccassi wrote:


This is not a hard technical problem with no known solution that we
are asking for design guidance on. This is a trivial technical
problem with a hard social conflict at its core. What we are really
blocked on is that the current owner of os-release refuses to let us
fix it.
This is an unfair and inaccurate summary. The policy question of "should 
testing and unstable be differentiated by os-release" isn't 
straightforward, and there isn't consensus that the answer should be 
"yes", as you would like it to be.


Debian's current (and long-standing) answer to that question is "no", 
and my view is that you have not advanced a sufficiently compelling case 
that this answer should be changed.


Regards,

Matthew

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 04:12, Sean Whitton  wrote:
>
> Hello Gioele,
>
> On Mon 05 Aug 2024 at 08:34am +02, Gioele Barabucci wrote:
> > 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?
>
> We could.  Generally, however, the ctte is designed to break ties
> between proposed solutions.  If the next thing to be done is design work
> to come up with a solution, then it is probably preferable for it to
> come back to ctte only after that work has been done.

If you _can_ then I'd ask to please do so, so that we can stop getting
mired in endless nitpicking about implementation details. The
technical side is beyond trivial, it's one line of text to fix, and
there's millions of ways to achieve that, some good and easy, some
horrible and complex, and all the spectrum in between, some of which
were mentioned in this long thread and some that weren't, but none of
that matters. This is not a hard technical problem with no known
solution that we are asking for design guidance on. This is a trivial
technical problem with a hard social conflict at its core. What we are
really blocked on is that the current owner of os-release refuses to
let us fix it. If you rule on what Gioele said, and the decision is to
overrule the block, transferring ownership of os-release if needed,
then the people interested in fixing this can actually be empowered to
find a way that works in practice to do so and implement it, without
the distraction of trying to concoct a solution that feels good and
aesthetically appealing in the aseptic, abstract context of an email
thread to convince you to vote one way or the other.

> And in the meantime, it might be that all parties like the proposed
> solution and are happy to have it in the archive, such that ctte
> involvement is not required after all.

This is not going to happen, as already mentioned various people have
tried for at least 12 years to get os-release fixed, one more month or
one more year or one more decade is not going to change anything.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst  wrote:
>
> On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst  wrote:
> > >
> > > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > > > > 2) Testing and unstable can continue to remain indistinguishable, 
> > > > > > and
> > > > > > both be erroneously identified as trixie
> > > > >
> > > > > Isn't there the third option of adhering to the os-release 
> > > > > specification
> > > > > without making testing and unstable distinguishable? I did not see 
> > > > > this
> > > > > ranked in your preference. Do you see it as even worse than the status
> > > > > quo?
> > > >
> > > > There isn't such option. Adhering to the specification means
> > > > identifying them separately, given they can be built separately, ran
> > > > separately, managed separately. So the option you are referring to is
> > > > for the opposite: _not_ adhering to the specification, and yes, that
> > > > is an option.
> > >
> > > For completion's sake:
> > >
> > > There is a third option of updating the os-release specification to
> > > declare that there is no relevant difference between distributions such
> > > as Debian's testing and unstable (for some definition of a class of
> > > distributions that would encompass the two) and that it is not necessary
> > > for os-release files to distinguish between them.
> > >
> > > I make no statement as to whether this is a good idea or not, but it is
> > > definitely a possibility.
> >
> > That would make it contradictory with itself and everything else that
> > uses it, so it's not a change that would be acceptable.
>
> Why not?

Because A is A, not B.

> You seem to hold the opinion in this discussion that the os-release
> specification is perfect and that Debian's implementation of it is
> wrong and should be corrected and there is no discussion.
>
> I'm not saying that's not true, but it does make it more difficult to
> understand the reasoning.

Nobody said anything is perfect. You can check the git history and see
that it gets updated from time to time, proving the opposite.
However, this doesn't mean that _any_ request is reasonable. This one
is not. Debian's implementation in sid is buggy, end of - it says sid
is trixie, instead of saying that sid is sid. Again, you can argue
that it's fine to leave it buggy - that's ok. You cannot argue that
the math book is wrong and Debian is right to say that 2+2=5.

> You want to update the implementation in Debian to more closely match
> the specification. I and others have asked you what the benefit of this
> would be, but TTBOMK the answers you have given all essentially boiled
> down to "because that is what the standard requires", and/or "because
> people might want to know the difference between the two", without going
> into detail or providing real-world examples as to why this would be the
> case. I myself have even given a real-world example, but then it turned
> out that this was not even a good idea and Helmut Grohne showed me a
> better way to implement what I needed to do.

Please see (plenty) of other mails. I know there's a lot of noise and
it takes time to sift through the walls of texts, but that's why I do
not want to add even more. I added multiple examples, others added
theirs, there's no point in piling up even more, there's plenty
already for the undecided, and those whose minds were already made
before even reading the subject line won't bulge anyway.

> Given the what we know so far, in my opinion (for as much as that one
> holds merit), Debian should declare that we implement the os-release
> specification only from the time of the release of our distribution
> suites, and that the data in the os-release file before that (i.e., in
> our development suites) could be right or could be wrong but that we do
> not warrant that it is either way.

That's not what happens right now though - the file is there, so it is
implemented.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst  wrote:
> >
> > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > > > both be erroneously identified as trixie
> > > >
> > > > Isn't there the third option of adhering to the os-release specification
> > > > without making testing and unstable distinguishable? I did not see this
> > > > ranked in your preference. Do you see it as even worse than the status
> > > > quo?
> > >
> > > There isn't such option. Adhering to the specification means
> > > identifying them separately, given they can be built separately, ran
> > > separately, managed separately. So the option you are referring to is
> > > for the opposite: _not_ adhering to the specification, and yes, that
> > > is an option.
> >
> > For completion's sake:
> >
> > There is a third option of updating the os-release specification to
> > declare that there is no relevant difference between distributions such
> > as Debian's testing and unstable (for some definition of a class of
> > distributions that would encompass the two) and that it is not necessary
> > for os-release files to distinguish between them.
> >
> > I make no statement as to whether this is a good idea or not, but it is
> > definitely a possibility.
> 
> That would make it contradictory with itself and everything else that
> uses it, so it's not a change that would be acceptable.

Why not?

You seem to hold the opinion in this discussion that the os-release
specification is perfect and that Debian's implementation of it is
wrong and should be corrected and there is no discussion.

I'm not saying that's not true, but it does make it more difficult to
understand the reasoning.

I happen to be involved with NBD upstream, and as such have worked on
the specification of the NBD protocol. I *could* declare in that
specification that any system that implements the NBD protocol MUST (in
an RFC 2119 sense) make sure that port 10809 (assigned by IANA to NBD)
can only ever be used for NBD, but that would be unreasonable and is not
going to fly, and any implementor of the NBD protocol would be well
within their rights to ignore that part of the specification, in
contradiction of the standard.

In a similar sense, I feel that it's not entirely unreasonable for a
distribution to declare that a part of the os-release specification is
making unreasonable demands of a distribution in certain situations, and
that to implement those parts of the specifications is too much effort
and therefore will not happen, in contradiction of the standard. Perhaps
this could be one of those situations.

You want to update the implementation in Debian to more closely match
the specification. I and others have asked you what the benefit of this
would be, but TTBOMK the answers you have given all essentially boiled
down to "because that is what the standard requires", and/or "because
people might want to know the difference between the two", without going
into detail or providing real-world examples as to why this would be the
case. I myself have even given a real-world example, but then it turned
out that this was not even a good idea and Helmut Grohne showed me a
better way to implement what I needed to do.

I would like to request that you give this a real hard thought, and try
to come up with a good description of some realistic scenarios where the
current state of affairs is problematic, how it is problematic, and how
the proposed change would resolve that. There are after all real costs
involved to the suggestions you have made; updating packages in the
Essential set is not trivial, and can have distribution-wide impacts on
far more packages than just the ones that are being changed. Going
through testing-proposed-updates, as you have proposed, requires manual
work from the release team, updates to the dak software to special-case
the os-release package, or both. And even the mere idea of having an
easily-distinguishable difference between testing and unstable could
cause packages to behave differently between testing and unstable, which
would invalidate the whole reason we even have that distinction between
testing and unstable in the first place. And while maintaining a package
that ships a five-line file (plus supporting scripts and a changelog) is
trivial, the ancillary work involved in making this happen, and the
resulting effects that could occur, is decidedly not trivial. So, in
order for the ctte to consider this[1], I think it is necessary for them
to be able to do a proper cost-benefit analysis, which would involve
knowing what the benefits are beyond a desire to be compatible with some
external standard and a vague handwavy "this is what people might do"
statement, that being all you have given so far.

Given the what we know so far, in my opini

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

On Mon 05 Aug 2024 at 12:21pm +01, Luca Boccassi wrote:

> On Mon, 5 Aug 2024 at 03:15, Sean Whitton  wrote:
>>
>> Hello,
>>
>> So far, although many people are sympathetic to the frustration at
>> distinguishing testing from unstable in practice, I don't believe anyone
>> has spoken in favour of overriding Santiago, besides Luca.
>
> To clarify, do you mean "TC members" here instead of the more generic
> "people"?

I few people spoke up after I wrote my message.  But TC members are who
I think we need to hear from for procedural purposes.

>> Also, the Release Team aren't happy with Luca's plan, so even if the TC
>> were to override Santiago, it might be moot, because the TC can't
>> override delegate decisions.
>
> That is not how I read those messages though? I do not see vetoes.

Helmut and I have both read them as stronger rejections than you have.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello Gioele,

On Mon 05 Aug 2024 at 08:34am +02, 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.

Thank you very much for providing input.

> [...]
> 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?

We could.  Generally, however, the ctte is designed to break ties
between proposed solutions.  If the next thing to be done is design work
to come up with a solution, then it is probably preferable for it to
come back to ctte only after that work has been done.

And in the meantime, it might be that all parties like the proposed
solution and are happy to have it in the archive, such that ctte
involvement is not required after all.

For example, perhaps someone is able to develop a solution that solves
people's scripting needs without really settling the question as to what
extent we should officially distinguish between testing and unstable.

If we were to vote "no" on the resolution you propose then we block
people from being creative in this area.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 13:04, Luca Boccassi  wrote:
>
> On Mon, 5 Aug 2024 at 08:42, Helmut Grohne  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.

And to be clear, of course if RT now replies with something along the
lines of "this is an official veto to the use of t-p-u from RT", then
I'll pick one of the alternatives that do not involve t-p-u

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 08:42, Helmut Grohne  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  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.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 08:39, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote:
> > Validating is of course necessary. If the worry is around changing the
> > dependencies of base-files, I would be happy to carry the dependency on
> > a new os-release binary package in init-system-helpers, which is
> > already Essential: yes. I already did something similar in Bookworm to
> > force all installations to become usrmerged, and I do not recall issues
> > with the bootstrapping order. This would be even easier in practice as
> > the new package would have a single file, no maintainer scripts, no
> > dependencies and no build dependencies. Would that solve your concerns?
>
> No. You need to decide whether /etc/os-release is to be essential or
> not.
>
> If it is, then your proposed dependency in init-system-helpers does not
> cut it, because I can simply upgrade base-files before
> init-system-helpers and then my /etc/os-release is gone violating Debian
> policy. A more reliable mechanism for transitioning essential files is
> required.

Sure, but violating debian policy is something that happens when it's
needed or worth doing, and then it's dealt with if it actually becomes
a problem. In _practice_ I doubt that would create actual issues,
given it requires manually hold back the update of one but not the
other. In practice, a synchronized upload should be more than enough
to avoid real issues. This is something that could be established with
QA effort once it's implemented as POC.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 09:39, Marc Haber  wrote:
>
> On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote:
> > * Some package, let's call it foobar, reads os-release and changes its
> >   behaviour according to whether it sees trixie/testing or unstable
> >
> > * foobar_1.2-3 is in unstable and works correctly there
> >
> > * The testing migration scripts let it migrate
> >
> > * trixie's os-release is different from unstable's (this is the essence
> >   of what Luca is asking for)
> >
> > * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves
> >   incorrectly
> >
> > * Now our mechanisms to avoid regressions in testing have failed to
> >   prevent a regression, because the regression was never visible to users
> >   of unstable, and in fact didn't exist until foobar migrated
>
> That can happen the same way when a package trips over VERSION and
> VERSION_ID suddenly appearing.
>
> While you have a point here, I think that the current state is an
> expression of us valueing our toolchain and processes higher than the
> needs of users of testing. By having our development repositories out in
> the open we are literally inviting people to use it. In fact, that's an
> important part of our QA. We should not make life harder for those
> people.

That, and also this objection assumes it's impossible to tell them
apart right now. It's not, as already shown many times, it just
requires to open code annoying Debian-specific workarounds. But if
anybody wants, they can do it. I know, because I do it in many places
already.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 12:21, Luca Boccassi  wrote:
>
> On Mon, 5 Aug 2024 at 03:15, Sean Whitton  wrote:
> >
> > Hello,
> >
> > So far, although many people are sympathetic to the frustration at
> > distinguishing testing from unstable in practice, I don't believe anyone
> > has spoken in favour of overriding Santiago, besides Luca.
>
> To clarify, do you mean "TC members" here instead of the more generic
> "people"? Because there have been a few people speaking in favour,
> with varying degrees of enthusiasm. But please note that I have not
> publicized this anywhere, so only somebody who follows CTTE's bugs
> would have noticed. If you are looking for more people (outside of TC
> members) to chime in, I can try and make that happen, but I wasn't
> aware this was a requirement.
>
> > Also, the Release Team aren't happy with Luca's plan, so even if the TC
> > were to override Santiago, it might be moot, because the TC can't
> > override delegate decisions.
>
> That is not how I read those messages though? I do not see vetoes.
> There were legitimate concerns raised about QA efforts, and manual
> efforts, which I think I have answered - at least there hasn't been
> any comeback on those answers.
>
> As far as I can tell, testing-proposed-updates is a fully supported
> mechanism, our dev ref even mentions it:
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u
>
> I believe the change being talked about respects all the points and
> requirements listed on that page. If there are more that are not
> present there, I would ask that they be documented in the same place -
> this would generally be useful, not just for this instance.

Also, using t-p-u is only one mechanism, there are more mentioned in
another mail. I'd rather not do extra work if a better mechanism is
there, but if that cannot be used for any reason, then I would do such
extra work and avoid t-p-u.

As mentioned before, I am not asking to modify testing/trixie in any
way. I am asking to modify sid. If what I propose was implemented
right now, trixie would be exactly as it is now. It's sid that would
change from VERSION_CODENAME=trixie to VERSION_CODENAME=sid.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 03:15, Sean Whitton  wrote:
>
> Hello,
>
> So far, although many people are sympathetic to the frustration at
> distinguishing testing from unstable in practice, I don't believe anyone
> has spoken in favour of overriding Santiago, besides Luca.

To clarify, do you mean "TC members" here instead of the more generic
"people"? Because there have been a few people speaking in favour,
with varying degrees of enthusiasm. But please note that I have not
publicized this anywhere, so only somebody who follows CTTE's bugs
would have noticed. If you are looking for more people (outside of TC
members) to chime in, I can try and make that happen, but I wasn't
aware this was a requirement.

> Also, the Release Team aren't happy with Luca's plan, so even if the TC
> were to override Santiago, it might be moot, because the TC can't
> override delegate decisions.

That is not how I read those messages though? I do not see vetoes.
There were legitimate concerns raised about QA efforts, and manual
efforts, which I think I have answered - at least there hasn't been
any comeback on those answers.

As far as I can tell, testing-proposed-updates is a fully supported
mechanism, our dev ref even mentions it:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u

I believe the change being talked about respects all the points and
requirements listed on that page. If there are more that are not
present there, I would ask that they be documented in the same place -
this would generally be useful, not just for this instance.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Mon, 5 Aug 2024 at 01:07, Timo Röhling  wrote:
>
> Hi,
>
> * Luca Boccassi  [2024-08-03 16:15]:
> >The only question is whether they do that and then say "it's nice
> >that we have a common, standard, agnostic way of figuring this out
> >and it just works (TM) on Debian too", or, "man this Debian thing
> >sure is a gigantic pile of rubbish, it's so painful to deal with it
> >as opposed to literally everything else, why do I even bother with
> >it".
> >[...]
> >The only thing you can do as a TC member is decide whether users
> >should continue to curse Debian while they do have to open-code bad
> >workarounds exclusively for it
> Can we please dial down on the hyperbole? This is not some teenage
> drama about the Cool Kids stopping to like us if we don't do This
> Random Thing, so let's keep it about the technical implications.

I assure you this was no hyperbole, but a real-life example. There was
lots and lots of cursing involved.

> >I just showed you - I have two images, with radically different
> >lifecycles, and I cannot tell them apart. I can tell apart any other
> >version of any other distribution, not this one. That's a negative
> >consequence for me. If you meant to say it's ok for you that there is
> >such a negative consequence for me, well, ok, that's not great, but
> >fine I guess. But it should be pretty obvious that it is negative for
> >me: I am telling you it is.
> Can you be a bit more specific about the negative consequences? You
> seem to imply that distinguishing testing and unstable images is
> desirable just for the sake of it. Yet I cannot (painlessly)
> distinguish a Debian image that has been created with debootstrap
> from one that has been created with mmdebstrap either, and I'm not
> losing sleep about it.

The image tool used to build an image doesn't change which release is
built. Stamping the image with the origin wouldn't be a bad idea,
though - perhaps we should teach our image building tools to take
/usr/lib/os-release, and create /etc/os-release (replace the symllink)
with it as a base, adding metadata about the image created such as
what you suggest.
The negative consequences I think were already shown through the
thread - not being able to distinguish between a bookworm image and a
bullseye image would be a problem, and this is the same. The entire
reason os-release exists is to tell you such things, and right now sid
is buggy, as it says it's trixie, but it's not.

> >If trixie was identified as trixie, and sid was identified as
> >unstable, what compromise would be, er, compromised, precisely?
> Unstable would become less useful at weeding out bugs in packages
> before they reach testing, which is pretty much the main reason for
> unstable to exist in the first place.
>
> Of course, this is not an absolute. Maybe following your proposal
> has such a big advantage for Debian and its users that we should
> accept this drawback. I just have not seen that argument yet.

I'm not sure I follow. Why would that be the case? Why would fixing a
line in a text file cause more bugs? Are you assuming it's impossible
right now to distinguish testing vs unstable? Because that is most
definitely not the case. It is possible, just horrible to do, and
requires Debian-specific kludges. But it can, and it routinely is
done, with much pain involved.

> >The lifecycle is what matters for os-release. This is an extremely
> >important distinction and it is crucial here, because this is what
> >os-release is about, and this bug is about os-release and its
> >implementation, not about generic ideas.
> I understand why this distinction is important for the os-release
> spec, but that does not automatically make it important for Debian
> users as well. Let me concede that people tend to use testing and
> unstable as if they were official Debian releases. So what would be
> a workflow that is hampered by the current situation? What do people
> *actually* do that makes your proposed change useful to them?

I showed some commands and tools that I personally use to identify
what is this image that I have lying around, in a cross-distro and
agnostic way, which doesn't work exclusively for Debian, and works
everywhere else. I build a lot of images, and I maintain a fair few
image building tools, so this matters to me, and to anybody else doing
similar things, and probably much more. The first time this bug was
raised was 12 years ago (linked in the first mail), so it's definitely
not just me.

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote:
> * Some package, let's call it foobar, reads os-release and changes its
>   behaviour according to whether it sees trixie/testing or unstable
> 
> * foobar_1.2-3 is in unstable and works correctly there
> 
> * The testing migration scripts let it migrate
> 
> * trixie's os-release is different from unstable's (this is the essence
>   of what Luca is asking for)
> 
> * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves
>   incorrectly
> 
> * Now our mechanisms to avoid regressions in testing have failed to
>   prevent a regression, because the regression was never visible to users
>   of unstable, and in fact didn't exist until foobar migrated

That can happen the same way when a package trips over VERSION and
VERSION_ID suddenly appearing.

While you have a point here, I think that the current state is an
expression of us valueing our toolchain and processes higher than the
needs of users of testing. By having our development repositories out in
the open we are literally inviting people to use it. In fact, that's an
important part of our QA. We should not make life harder for those
people.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Mon, 05 Aug 2024 at 09:02:51 +0200, Marc Haber wrote:
> On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote:
> > > If trixie was identified as trixie, and sid was identified as unstable,
> > > what compromise would be, er, compromised, precisely?
> > Unstable would become less useful at weeding out bugs in packages before
> > they reach testing,
> 
> Can you elaborate on that? Why does providing more and better
> information make it harder to identify bugs?

I think the concern is somewhere along these lines:

* Some package, let's call it foobar, reads os-release and changes its
  behaviour according to whether it sees trixie/testing or unstable

* foobar_1.2-3 is in unstable and works correctly there

* The testing migration scripts let it migrate

* trixie's os-release is different from unstable's (this is the essence
  of what Luca is asking for)

* Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves
  incorrectly

* Now our mechanisms to avoid regressions in testing have failed to
  prevent a regression, because the regression was never visible to users
  of unstable, and in fact didn't exist until foobar migrated

(All of this assumes the current state, where trixie = testing. The
same would be true, with appropriate name changes, during development
of forky or later.)

That's my understanding of why we try to make unstable as similar as
possible to a hypothetical future state of testing, and ideally
programmatically indistinguishable - unless you specifically go looking
at the apt configuration, at which point you're responsible for looking
at the *whole* apt configuration, and not just trying to derive a single
suite name from it.

A mitigation is that when autopkgtest tests a proposed migration, what
it is actually testing is a hypothetical future state of testing where
we pretend that this one package and its mandatory dependencies have
already migrated, in order to answer the question: if we really allowed
this package to migrate, would it break anything?

So if foobar has good enough autopkgtest coverage, *that* would stop it
migrating - but this is also why it's important that autopkgtests work
with the apt configuration that they're given (as Helmut described in more
detail in )
instead of figuring out whether they're on testing or unstable and
then using that information (and only that information) to construct a
test fixture.

There is a completely valid trade-off to be made about whether the
concern that I've described here (or similar reasons why testing and
unstable should be hard to distinguish) is more or less important than
the reasons why Luca and others want testing and unstable to be easy to
distinguish. That's fine! We make decisions all the time about which
option is better, or about which option is less-bad. But I think it's
an over-simplification to imply that this is a decision with only valid
arguments in one direction, and no valid arguments in the other. When
I talk about seeing both sides of a dispute, this is part of what I mean.

smcv
not a TC member

Bug#1077764: Ruling request on os-release specification implementation

[Gioele Barabucci]

On 05/08/24 09:38, Helmut Grohne wrote:

| The Technical Committee restricts itself to choosing from or adopting 
compromises between solutions and decisions which have been proposed and 
reasonably thoroughly discussed elsewhere.


The path forward is then, to freeze this discussion and «reasonably 
thoroughly discuss» a couple of alternative proposal off-bug. Where?


The discussion in this bug report got to its current size also because 
multiple issues are being discussed the same time:


a) whether to distinguish between testing/unstable,
b) how that distinction should be encoded in os-release,
c) how to package os-release,
d) whether to include version numbers, etc.

A discussion that assumes a) and focuses on creating a couple of PoCs to 
test the technical aspects b) and c) will surely be more conductive to 
concrete results.




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).


/usr/lib/os-release represents what the distro thinks of itself.

/etc/os-release represents the administrative choices of the local sysadmin.

Regards,

--
Gioele Barabucci

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

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

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote:
> Validating is of course necessary. If the worry is around changing the
> dependencies of base-files, I would be happy to carry the dependency on
> a new os-release binary package in init-system-helpers, which is
> already Essential: yes. I already did something similar in Bookworm to
> force all installations to become usrmerged, and I do not recall issues
> with the bootstrapping order. This would be even easier in practice as
> the new package would have a single file, no maintainer scripts, no
> dependencies and no build dependencies. Would that solve your concerns?

No. You need to decide whether /etc/os-release is to be essential or
not.

If it is, then your proposed dependency in init-system-helpers does not
cut it, because I can simply upgrade base-files before
init-system-helpers and then my /etc/os-release is gone violating Debian
policy. A more reliable mechanism for transitioning essential files is
required.

If it is not, then demoting it to Priority:required is an option. In
this case, init-system-helpers should not depend on it and rather the
priority would cause debootstrap to include it. On the flip side, that
means that all users of os-release would need a dependency on
"os-release | base-files (<< ...)". I suppose no work has been done to
gauge the impact of this.

I fear it's not that simple.

Helmut

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote:
> Yet I cannot (painlessly) distinguish a Debian image that
> has been created with debootstrap from one that has been created with
> mmdebstrap either, and I'm not losing sleep about it.

Still it would actually be nice to have an indication somewhere in /etc
indicating what software suite (installer, debootstrap, mmdebstrap,
live-installer etc) generated the image. Thanks for that idea!

> > If trixie was identified as trixie, and sid was identified as unstable,
> > what compromise would be, er, compromised, precisely?
> Unstable would become less useful at weeding out bugs in packages before
> they reach testing,

Can you elaborate on that? Why does providing more and better
information make it harder to identify bugs?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1077764: Ruling request on os-release specification implementation

[Gioele Barabucci]

On Mon, 05 Aug 2024 10:12:40 +0800 Sean Whitton 
 wrote:

So far, although many people are sympathetic to the frustration at
distinguishing testing from unstable in practice, I don't believe anyone
has spoken in favour of overriding Santiago, besides Luca.


Hi,

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.


(I prefer this framing to "overriding Santiago".)

Allow me to, although late and without having read the whole thread, to 
add a relevant point.


There are open bugs about lsb_release being unable to distinguish 
between testing and unstable.


Other DDs are already suggesting involving the CTTE to force lsb-release 
to gain support for that distinction (latest example: 
).


If this bug is closed and no information is added to os-release, then 
the CTTE will be asked in the future to 1) override my decision to not 
ship a Debian-specific patch in src:lsb-release-minimal, and 2) to 
discuss how to exactly distinguish between testing and unstable so that 
a Debian-specific patch can be added (and various messages in this 
thread already show that that is a complex and controversial task.)


My opinion is that by deciding to not ship enough information in 
/usr/lib/os-release to distinguish between testing and unstable the CTTE 
is just pushing that same issue into a myriad of other packages.




Also, the Release Team aren't happy with Luca's plan, so even if the TC
were to override Santiago, it might be moot, because the TC can't
override delegate decisions.


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?


Regards,

--
Gioele Barabucci

Bug#1077764: Ruling request on os-release specification implementation

[Joseph R. Justice]

Apologies for formatting of the following; I'm reading this using Gmail on
an Android tablet with a virtual keyboard.

I've read much but not necessarily all of the thread, so the following
might have been mentioned and dismissed already.  My apologies if this is
the case.

Reading the thread, it seems to me that people use or can use unstable
(sid), testing (currently to-become trixie / 13), and stable (currently 12)
for several different purposes, some of which contradict.  People using one
of the suites want a value for os-release that matches the purpose they
have for using that suite.

People using unstable as a distribution in its own right, irregardless of
the fact that it is the entry point for packages to enter testing (which
will-become currently trixie / 13), want a value for os-release to indicate
that (presumably unstable or sid).

People using unstable as an entry point for packages to enter testing
(which will-become currently trixie / 13) en route to entering the next
stable release want a value for os-release to indicate what testing
will-become (e.g. currently trixie).

People using testing as an entry point for packages to enter the next
stable release (currently trixie / 13) want a value for os-release to
indicate the next stable release (currently trixie).

There may be people using testing as a distribution in its own right,
irregardless to what it will-become, similarly to how some people use
unstable; presumably such people would want a value for os-release to
indicate that (e.g. testing).

People using the-current stable as a distribution that will never change
without explicit action on their part, e.g. it will always stay that
distribution until and unless they actively change it, want a value for
os-release matching the distribution they are using, e.g. they want it to
currently be the code name for 12, and if and when they change it they want
it to become trixie.

People using the-current stable as a distribution that may (will) change
without action on their part, e.g. when the value of stable changes their
system will auto-magically change without them having to do anything (note,
this choice is discouraged by the Debian Project), may want a value for
os-release to indicate that (e.g. stable, as opposed to a specific
distribution name like trixie).

It occurs to me, perhaps naively or incorrectly, that this is the sort of
thing that virtual packages, and Provides / Conflicts declarations,
address.  People could pick a package for their system that provides the
meaning of os-release matching the distribution they are using and the
purpose they are using that distribution for.

I recognize that, even if this idea is deemed a good and desirable one, it
may not be possible to implement it immediately but may require a release
cycle or two to fully implement.

Hope this is of some use, interest.  Thanks for your time.  Be well.


Joseph

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

So far, although many people are sympathetic to the frustration at
distinguishing testing from unstable in practice, I don't believe anyone
has spoken in favour of overriding Santiago, besides Luca.

Also, the Release Team aren't happy with Luca's plan, so even if the TC
were to override Santiago, it might be moot, because the TC can't
override delegate decisions.

Could members of the TC who haven't shared an opinion yet please
indicate whether they think they might vote to override Santiago?  If
you wouldn't, and your view is not obvious from other posting, please
say that too.

Then if it becomes clear there is no appetite to override, we can close
this bug which is already gathering a lot of text.

Thanks.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Timo Röhling]

Hi,

* Luca Boccassi  [2024-08-03 16:15]:
The only question is whether they do that and then say "it's nice 
that we have a common, standard, agnostic way of figuring this out 
and it just works (TM) on Debian too", or, "man this Debian thing 
sure is a gigantic pile of rubbish, it's so painful to deal with it 
as opposed to literally everything else, why do I even bother with 
it".

[...]
The only thing you can do as a TC member is decide whether users 
should continue to curse Debian while they do have to open-code bad 
workarounds exclusively for it
Can we please dial down on the hyperbole? This is not some teenage 
drama about the Cool Kids stopping to like us if we don't do This 
Random Thing, so let's keep it about the technical implications.



I just showed you - I have two images, with radically different
lifecycles, and I cannot tell them apart. I can tell apart any other
version of any other distribution, not this one. That's a negative
consequence for me. If you meant to say it's ok for you that there is
such a negative consequence for me, well, ok, that's not great, but
fine I guess. But it should be pretty obvious that it is negative for
me: I am telling you it is.
Can you be a bit more specific about the negative consequences? You 
seem to imply that distinguishing testing and unstable images is 
desirable just for the sake of it. Yet I cannot (painlessly) 
distinguish a Debian image that has been created with debootstrap 
from one that has been created with mmdebstrap either, and I'm not 
losing sleep about it.


If trixie was identified as trixie, and sid was identified as 
unstable, what compromise would be, er, compromised, precisely?
Unstable would become less useful at weeding out bugs in packages 
before they reach testing, which is pretty much the main reason for 
unstable to exist in the first place.


Of course, this is not an absolute. Maybe following your proposal 
has such a big advantage for Debian and its users that we should 
accept this drawback. I just have not seen that argument yet.


The lifecycle is what matters for os-release. This is an extremely 
important distinction and it is crucial here, because this is what 
os-release is about, and this bug is about os-release and its 
implementation, not about generic ideas.
I understand why this distinction is important for the os-release 
spec, but that does not automatically make it important for Debian 
users as well. Let me concede that people tend to use testing and 
unstable as if they were official Debian releases. So what would be 
a workflow that is hampered by the current situation? What do people 
*actually* do that makes your proposed change useful to them?



Cheers
Timo

PS. I'm emailing out of vacation, so it might take me a few days to 
reply again.



--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Wouter,

I am continuing the off-topic part below. Earlier, in this discussion I
noted that being able to distinguish testing and unstable is rarely the
right thing to do. I'll use your nbd example to show why. Everyone not
interested in nbd autopktests may stop reading here.

On Sun, Aug 04, 2024 at 08:02:37PM +0200, Wouter Verhelst wrote:
> This is off-topic for the ctte discussion, but: this part of the
> autopkgtest is about testing the initrd scripts in the nbd package,
> which you can only do by booting a VM image. This requires us to
> generate something that can be booted over an NBD connection, which we
> do by way of "debvm-create" (whose implementation uses debootstrap).
> We then export this generated image through the nbd server that is
> installed in the testbed, and then use "debvm-run" to boot the image
> over NBD.

I note that an early version of the debvm autopkgtest worked the same
way until Paul kindly sat down with me and explained to me why I am
doing it wrong.

> This is very much a corner case, but *in order* for me to test what the
> testbed provides, I need to know what it is, exactly, that it is
> providing, and that does not appear to be in the autopkgtest API beyond
> the "use what is installed", and that just doesn't work when I need to
> generate a bootable image.

It does work! It's not exactly what the testbed provides that we need,
but the testbed's apt configuration (i.e. its sources and its apt pins).

> Perhaps if autopkgtest were to pass debootstrap arguments to be used for
> creation of a chroot if the test requires it, then I could stop using my
> script, but in the mean time...

Thankfully, Johannes turned those arguments into a mmdebstrap hook and
all you get to do is pass

-hook-dir=/usr/share/mmdebstrap/hooks/copy-host-apt-sources-and-preferences

to mmdebstrap (or debvm-create as a pass-through option). No, this does
not work with debootstrap, because debootstrap does not use apt for
dependency resolution and presently has no way of using the configured
apt pins.  In theory, it should be possible to construct an apt
repository containing the packages as pinned in autopkgtest, but no such
thing exists as of now. So as long as you accept that you cannot do such
testing using debootstrap and have to use mmdebstrap, you're good. Your
mirror specification should be an empty string (""). Consider reading
the debvm or mmdebstrap autopkgtests for details.

I see that you already are using the hook and all you get to do now is
pass an empty suite and profit. Untested sketch:

--- a/debian/tests/initrd-boot
+++ b/debian/tests/initrd-boot
@@ -7,13 +7,6 @@
 # of our VM image below)
 chmod a+rx "$TMPDIR"

-source /etc/os-release
-
-if [ -z "$VERSION_ID" ]; then
-RELEASE=$(perl debian/tests/get-deb-codename.pl)
-else
-RELEASE="${VERSION_CODENAME:-unstable}"
-fi
 eval "$(grep "^ID=" /etc/os-release)"
 if [ "$ID" = "ubuntu" ]; then
 COMPONENTS=main,universe
@@ -34,7 +27,7 @@
 IMAGE="$TMPDIR"/nbd.img
 debvm-create \
 --output="$IMAGE" \
---release="$RELEASE" \
+--release="" \
 --size=4G \
 --sshkey="$TMPDIR"/id_rsa.pub \
 --skip=usrmerge \
@@ -47,6 +40,7 @@
 --include="$INCLUDES${INCLUDES+,}nbd-client" \
 --components="$COMPONENTS" \
 $EXTRAS
+""

 # Configure and start up the nbd-server pointing at the new VM image
 cat > "$TMPDIR"/myvm.conf << EOF

Helmut

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst  wrote:
>
> On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > > both be erroneously identified as trixie
> > >
> > > Isn't there the third option of adhering to the os-release specification
> > > without making testing and unstable distinguishable? I did not see this
> > > ranked in your preference. Do you see it as even worse than the status
> > > quo?
> >
> > There isn't such option. Adhering to the specification means
> > identifying them separately, given they can be built separately, ran
> > separately, managed separately. So the option you are referring to is
> > for the opposite: _not_ adhering to the specification, and yes, that
> > is an option.
>
> For completion's sake:
>
> There is a third option of updating the os-release specification to
> declare that there is no relevant difference between distributions such
> as Debian's testing and unstable (for some definition of a class of
> distributions that would encompass the two) and that it is not necessary
> for os-release files to distinguish between them.
>
> I make no statement as to whether this is a good idea or not, but it is
> definitely a possibility.

That would make it contradictory with itself and everything else that
uses it, so it's not a change that would be acceptable.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > both be erroneously identified as trixie
> >
> > Isn't there the third option of adhering to the os-release specification
> > without making testing and unstable distinguishable? I did not see this
> > ranked in your preference. Do you see it as even worse than the status
> > quo?
> 
> There isn't such option. Adhering to the specification means
> identifying them separately, given they can be built separately, ran
> separately, managed separately. So the option you are referring to is
> for the opposite: _not_ adhering to the specification, and yes, that
> is an option.

For completion's sake:

There is a third option of updating the os-release specification to
declare that there is no relevant difference between distributions such
as Debian's testing and unstable (for some definition of a class of
distributions that would encompass the two) and that it is not necessary
for os-release files to distinguish between them.

I make no statement as to whether this is a good idea or not, but it is
definitely a possibility.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sun, Aug 04, 2024 at 01:00:38PM +0200, Paul Gevers wrote:
> Hi Wouter,
> 
> On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst  wrote:
> > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> > currently running". That code starts off with "parse os-release", and
> > then falls back to a horrible horrible perl script that parses
> > apt-cache policy output if os-release looks like testing or unstable,
> > because the autopkgtest needs to test the version that we're running,
> > not "always unstable", and this is just a pain. If os-release were to
> > distinguish "unstable" from "testing", then I would be able to get rid
> > of that perl script (and good riddance)
> 
> If I read correctly then what you describe here you fell in the trap that
> helmut mentioned earlier (but maybe you realized and implemented it
> correctly). You should run in the same environment that is prepared as your
> testbed.

This is off-topic for the ctte discussion, but: this part of the
autopkgtest is about testing the initrd scripts in the nbd package,
which you can only do by booting a VM image. This requires us to
generate something that can be booted over an NBD connection, which we
do by way of "debvm-create" (whose implementation uses debootstrap).
We then export this generated image through the nbd server that is
installed in the testbed, and then use "debvm-run" to boot the image
over NBD.

This is very much a corner case, but *in order* for me to test what the
testbed provides, I need to know what it is, exactly, that it is
providing, and that does not appear to be in the autopkgtest API beyond
the "use what is installed", and that just doesn't work when I need to
generate a bootable image.

Perhaps if autopkgtest were to pass debootstrap arguments to be used for
creation of a chroot if the test requires it, then I could stop using my
script, but in the mean time...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Sat, Aug 03, 2024 at 08:07:14PM +0200, Wouter Verhelst wrote:
> For what it's worth, I do have one argument in favour of your position.
> In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> currently running". That code starts off with "parse os-release", and
> then falls back to a horrible horrible perl script that parses
> apt-cache policy output if os-release looks like testing or unstable,
> because the autopkgtest needs to test the version that we're running,
> not "always unstable", and this is just a pain. If os-release were to
> distinguish "unstable" from "testing", then I would be able to get rid
> of that perl script (and good riddance)

I have a very similar problem in my ansible playbooks, with my fleet
containing both testing and unstable reference systems AND systems that
run testing but will automatically move to stable once testing is
released as stable.

I would also love to be able to get rid of my heuristics to distinguish
testing from unstable. My heuristics are not nearly as ugly as yours,
but I would not cry while removing them.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1077764: Ruling request on os-release specification implementation

[Paul Gevers]

Hi Wouter,

On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst  wrote:

In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
currently running". That code starts off with "parse os-release", and
then falls back to a horrible horrible perl script that parses
apt-cache policy output if os-release looks like testing or unstable,
because the autopkgtest needs to test the version that we're running,
not "always unstable", and this is just a pain. If os-release were to
distinguish "unstable" from "testing", then I would be able to get rid
of that perl script (and good riddance)


If I read correctly then what you describe here you fell in the trap 
that helmut mentioned earlier (but maybe you realized and implemented it 
correctly). You should run in the same environment that is prepared as 
your testbed. If you debootstrap a different environment, you're not 
testing what the testing migration wants you to test. Maybe you have 
assessed this and it can't be relevant for nbd, I don't know, but it's 
tricky for sure. IIRC I have filed bugs about this in the past (at least 
I discussed it extensively with helmut in Heidelberg last year) because 
the result can be (and has been IIRC) a wrong assignment of regression. 
What the test should ensure is that it tests the same combination that 
apt would provide to it, ideally by not fiddling. os-release doesn't 
help in the most important use case of autopkgtest, because it's not 
made to tell what apt would install if asked.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sun, 4 Aug 2024 at 00:25, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > A trixie image is now in development, will become stable at some point
> > next year, will gain security support where it now has none, then it
> > will pass to the LTS team, then it will go EOL and any installation will
> > have to move to trixie + 1 which will be forky. The same happened to
> > bookworm, the same will happen to forky. It is not a rolling release,
> > because it has a limited lifetime, that begins, develops and ends.
>
> This is not true of a testing image, which is indeed a rolling release
> (with a somewhat odd variation in the frequency with which new packages
> are rolled into the release) that never gains security support, never
> passes to the LTS team, and never goes EOL.  So whether this is true of an
> image installed from the current testing repository depends on the apt
> configuration in a way that is not captured by os-release under your
> proposal, namely whether it is configured to point to testing or to
> trixie.  It's the exact same package set, but a completely different
> lifecycle.
>
> This is somewhat similarly true of stable vs. bookworm, but pointing to
> stable rather than bookworm is generally not encouraged because the sudden
> upgrade behavior when we release a new stable can be surprising in a way
> that is generally the opposite of what one wants from using stable.  With
> testing, however, this is a standard configuration that is often
> preferable to using the codename, depending on what goals one has for
> running a testing image.  For example, every testing image that I have
> points to testing, not to trixie.

I do have 'stable' in my configuration on this machine, intentionally.
It doesn't suddenly become incorrect that os-release says
VERSION_ID=12 VERSION_CODENAME=bookworm, because it _is_ bookworm
right now. Once the next stable is out, it will be upgraded,
os-release included and it will say VERSION_ID=13 and it will still be
correct. Same for testing. This is not incompatible at all with
os-release, and in fact it works very nicely - it just means "when
this reaches the point of flipping to a different stage in the
lifecycle, upgrade me to the next version automatically when such
process runs next". If you build an image, _of course_ the metadata
will be correct at the point in time that image was created, if you
don't touch it, it cannot magically change, that's ok, and in no way
contradicts anything I've said or anything in the os-release spec, and
I don't see how it could - it would be useless if it broke 5 minutes
after an image was created. None of this means that bookworm or trixie
are rolling releases - they are not, they will both be EOL and need
replacements. If you build a testing image or a stable image or an
oldstable image you are just taking advantage of aliases to
automatically move between different releases when they reach certain
points in their lifecycles - we call these 'aliases', correctly, which
reflects this fact. If you run an upgrade workflow, however that might
look like, the content will change - that's ok! It's the point of
doing upgrades. If it's configured to do so, it will be a different
release after the upgrade, and its new metadata will reflect that.
What it could use to make it even more useful, is adding SUPPORT_END=
and RELEASE_TYPE= so that I can get extra information out of it -
however, these are cherries on top. And I don't _think_ we have fixed
EOL dates that can be set pre-emptively, while other distros do, so it
would have to be added on EOL date which is less useful, but perhaps
worth considering nonetheless. Again, not a deal breaker.

> > The purpose of os-release is to identify images that have such
> > differences, and give them metadata accurately describing their
> > differing lifecycles, which are different and distinct, have different
> > characteristics, reflecting in different fields being set, such as
> > SUPPORT_END.
>
> I think there is no way to fully satisfy that purpose in Debian without
> doing something dynamic based on the apt configuration.  Your proposal
> provides a different approximation that better captures one aspect of the
> lifecycle, but still does not achieve the semantics you're arguing for in
> the abstract.

Already explained above how this can and does work.

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  writes:

> A trixie image is now in development, will become stable at some point
> next year, will gain security support where it now has none, then it
> will pass to the LTS team, then it will go EOL and any installation will
> have to move to trixie + 1 which will be forky. The same happened to
> bookworm, the same will happen to forky. It is not a rolling release,
> because it has a limited lifetime, that begins, develops and ends.

This is not true of a testing image, which is indeed a rolling release
(with a somewhat odd variation in the frequency with which new packages
are rolled into the release) that never gains security support, never
passes to the LTS team, and never goes EOL.  So whether this is true of an
image installed from the current testing repository depends on the apt
configuration in a way that is not captured by os-release under your
proposal, namely whether it is configured to point to testing or to
trixie.  It's the exact same package set, but a completely different
lifecycle.

This is somewhat similarly true of stable vs. bookworm, but pointing to
stable rather than bookworm is generally not encouraged because the sudden
upgrade behavior when we release a new stable can be surprising in a way
that is generally the opposite of what one wants from using stable.  With
testing, however, this is a standard configuration that is often
preferable to using the codename, depending on what goals one has for
running a testing image.  For example, every testing image that I have
points to testing, not to trixie.

> The purpose of os-release is to identify images that have such
> differences, and give them metadata accurately describing their
> differing lifecycles, which are different and distinct, have different
> characteristics, reflecting in different fields being set, such as
> SUPPORT_END.

I think there is no way to fully satisfy that purpose in Debian without
doing something dynamic based on the apt configuration.  Your proposal
provides a different approximation that better captures one aspect of the
lifecycle, but still does not achieve the semantics you're arguing for in
the abstract.

-- 
Russ Allbery (r...@debian.org)  

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 19:28, Wouter Verhelst  wrote:
>
> On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote:
> > Testing and unstable have completely separate and independent
> > archives, you can point an image builder to one OR the other, in
> > isolation, and it will produce a fully complete and runnable and
> > bootable OS tree. The fact that they might have some or even all
> > content in common at particular points in time is orthogonal and
> > unrelated to what the purpose of os-release is.
>
> I suspect this is the crux of your problem. Perhaps it might be useful
> to explain what "the purpose of os-release" is, exactly? I suspect that
> most people here see testing as more similar to unstable than not, and
> in order for us to find common ground, understanding *why* this matters
> for os-release might be useful.

I mentioned this a few times through the thread, but there now are
walls upon walls of text, so it's worth repeating as it's very likely
that it's lost in this miasma of words.

A trixie image is now in development, will become stable at some point
next year, will gain security support where it now has none, then it
will pass to the LTS team, then it will go EOL and any installation
will have to move to trixie + 1 which will be forky. The same happened
to bookworm, the same will happen to forky. It is not a rolling
release, because it has a limited lifetime, that begins, develops and
ends.

A sid image will never become stable, will never gain security
support, will never pass to the LTS team, will never go EOL, such
installation was always sid, continues to be sid now, will always be
sid. It is a rolling release, because it has no beginning and no end,
and an installed image simply carries on.

Thus the lifecycles of a sid image and a trixie image are radically
distinct and separate. They can be created individually and
separately, they can be used individually and separately. They take
different paths through time.

The purpose of os-release is to identify images that have such
differences, and give them metadata accurately describing their
differing lifecycles, which are different and distinct, have different
characteristics, reflecting in different fields being set, such as
SUPPORT_END. The fact that content might be similar at some point in
time is irrelevant for os-release, oldstable and stable also have some
packages that are identical bit-by-bit and it doesn't matter at all:
lifecycles are what matters, content does not.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote:
> Testing and unstable have completely separate and independent
> archives, you can point an image builder to one OR the other, in
> isolation, and it will produce a fully complete and runnable and
> bootable OS tree. The fact that they might have some or even all
> content in common at particular points in time is orthogonal and
> unrelated to what the purpose of os-release is.

I suspect this is the crux of your problem. Perhaps it might be useful
to explain what "the purpose of os-release" is, exactly? I suspect that
most people here see testing as more similar to unstable than not, and
in order for us to find common ground, understanding *why* this matters
for os-release might be useful.

For what it's worth, I do have one argument in favour of your position.
In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
currently running". That code starts off with "parse os-release", and
then falls back to a horrible horrible perl script that parses
apt-cache policy output if os-release looks like testing or unstable,
because the autopkgtest needs to test the version that we're running,
not "always unstable", and this is just a pain. If os-release were to
distinguish "unstable" from "testing", then I would be able to get rid
of that perl script (and good riddance)

But I don't think that's the right answer, and it would be good if you
could clarify this.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> > 1) The os-release specification must be adhered to, and it must be
> > possible to tell the difference between testing vs unstable, and each
> > must be correctly identified by the respective metadata
>
> Given the state of discussion, I think it is fairly evident that we do
> not have consensus for the need to distinguish testing and unstable. We
> have people arguing in favour and we have people arguing against that.
> This is a point of disagreement.

I'm not sure "consensus for the need" is the right term here? People
obviously _do_ what I am speaking of. There might not be consensus
that's it's a good idea to do it, but it still happens, and it will
continue to happen, regardless of what is decided here. People do need
to distinguish it, whether the TC rules that it should be easy to do
so like in any other distro, or whether it rules that it will continue
to require annoying Debian-specific kludges, won't change this fact.

> > 2) Testing and unstable can continue to remain indistinguishable, and
> > both be erroneously identified as trixie
>
> Isn't there the third option of adhering to the os-release specification
> without making testing and unstable distinguishable? I did not see this
> ranked in your preference. Do you see it as even worse than the status
> quo?

There isn't such option. Adhering to the specification means
identifying them separately, given they can be built separately, ran
separately, managed separately. So the option you are referring to is
for the opposite: _not_ adhering to the specification, and yes, that
is an option.

Well, I guess there could be yet another option: stop making it
possible to create either testing or unstable images separately in the
first place, just like you cannot create a stable-proposed image.

> > Sorry but I do not think that is an accurate representation. First of
> > all, the implementation of the spec is bugged, period - it's not about
> > being pedantic about it, it's about being completely incompatible: sid
> > is identified as trixie, and that is just plain wrong, and there's no
> > room for interpretation, no matter how one might try to bend it. You
> > might say that you don't _care_ that the implementation is buggy, you
> > might even say that it is worth, nay _good_ it to leave it buggy - but
> > buggy it is, if I create a sid image, it will never in a million years
> > be trixie, and yet it says it's trixie.
>
> I think it has become abundantly clear that your view on this does not
> represent consensus of discussion participants. It is not as black and
> white as you paint it. Simon compared unstable to Ubuntu's proposed
> pocket. It also happens that testing and unstable share the same pool
> hierarchy and the vast majority of packages. On the other hand, Devuan
> operates as an overlay repository to be added on top of a Debian
> repository. I don't think it matters that Ubuntu's proposed is
> implemented as a partial distribution overlaid onto another as that's
> what other derivatives (that do update their os-release file) do as
> well.

Sure, there's no consensus on the solution, that's obvious otherwise I
would not have needed to open this in the first place, right? There
are some things that require opinions to converge - should this bug be
fixed? - and there are some things that just are - people create and
manage and run sid and trixie images independently, the implementation
of the spec in sid is buggy. These last two statements do not need
consensus, they are facts. Deciding what to do based on those facts
requires consensus on the solution to adopt, if any.
The example of Ubuntu's proposed pocket is wrong as already mentioned,
from the point of view of the os-release specification, which is what
matters here. You cannot create an ubuntu-proposed image without the
full release, so os-release is not concerned with it, and doesn't
mandate anything in particular. os-release concerns images that have a
lifecycle and their identification. Trixie has a lifecycle: it started
as a development release, it will be declared stable and start
receiving security support, it will move to ELTS, it will go EOL. sid
will not do any of these things, its lifecycle is entirely and
completely separate, it will always be sid, it will never be security
supported, it will never go EOL, and it is a rolling release. Once
more for those at the back: the _content_ is irrelevant, it can be
fixed, it can change a lot, it can be the same as different releases,
it can be partially the same, it can be completely different, it
doesn't matter one bit. The lifecycle is what matters for os-release.
This is an extremely important distinction and it is crucial here,
because this is what os-release is about, and this bug is about
os-release and its implementation, not about generic ideas. As already
mentioned many times, this bug is n

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher  wrote:
>
> On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> > Hi
> >
> > On 03-08-2024 11:58, Luca Boccassi wrote:
> > > > On the use of tpu:
> > > > Personally, until now I fail to see enough value of being able to
> > > > distinguish unstable and testing to give the package carrying
> > > > /etc/os-release a permanent exception via tpu.
> > >
> > > Thanks for chiming in - assuming for a moment that it is decided that
> > > the change will be implemented, do you see any technical obstacles in
> > > using t-p-u as proposed?
> >
> > The biggest reason I know against using tpu is that it currently isn't
> > receiving the same amount of testing (be it automatic (autopkgtest,
> > piuparts, in the future reproducibility) or human) as unstable-to-testing
> > migrations receive. For the automatic part, that's obviously a solvable
> > problem (and already on my todo list for YEARS), but currently not the case.
> > It also *always* requires human intervention by the Release Team. Another
> > issue issue with tpu is that binNMU'ing is more difficult (I assume that's
> > probably not very often relevant in the current case). I recall there are
> > more issues with tpu, but I have forgotten them. When I find them, I'll add
> > them.
>
> To add to that: tpu is used for exceptional cases only. Cases where we
> deem the result of the upload more important than the additional
> work required of a release team member. Cases where we deem RC bugs
> potentially introduced by missing QA for tpu uploads less severe than
> the issue we are trying to fix in testing. Essentially, if it is not a
> critical bug (think xz incident critical), going through tpu during non-freeze
> time never happens.
>
> For a package that is part of the essential set, having all the QA tools
> checking the consequences of the inclusion of this a package is really
> essential. Skipping out on QA checks for an essential packages that
> would normally run for typical unstable to testing migration puts even
> more pressure on the release team to make sure that accepting the
> package from tpu does not severly break testing.
>
> (As side note: in essentially all cases where I handled tpu uploads
> (that I remember) during non-freeze time, it was more effort to untangle
> unstable so I have asked maintainers explicitly to perform tpu uploads.)

In the generic case, sure, I see all of that making perfect sense.
This though is about one very specific and narrow case: an arch: all
package with a single, fixed and inert text file, that differs by one
line. No maintainer scripts that run on install/upgrades and could
fail, no programs that run on install, no dependencies that might not
be available or installable, one reverse dependency for one cycle to
ensure installation in existing images and then it will be removed.
And it's one upload at the beginning of a cycle, and then it stays
as-is for 2 years until the next, so there is no continued effort nor
need to watch it. At each cycle there is a lot of work to do to
prepare the next testing pocket I imagine - creating new aliases and
whatnot, so in the context of that and compared to the size of that
work, this appears to me as a minor addition, no? Which is not to say
it's nil or doesn't require any effort ofc. The QA effort I see is:
diffoscope old.deb new.deb and verify the difference is only in the
changelog entry and the VERSION_CODENAME= field. For this specific and
precise use case, do you see the requirement for any other QA effort
on top of this, and if so could you please clarify what it would
entail?

> Also, we have been pushing to keep testing and unstable as close as
> possible. Packages not migrating for some time are considered RC buggy
> to reduce the difference and where Paaul is thankfully filing the
> corresponding bugs. Going through tpu would essentially introduce a
> package that is auto-RC buggy in the essential set with consequences: it
> causes even more divergence for autopkgtests in testing (reference
> tests), in testing + pinned packages from unstable for migration checks
> and in unstable. That would cause potentially even more work (for the RT
> and maintainers) to figure out why some test is failing in one
> configuration and not the other.

I deal with fairly complex autopkgtest in debci all the time, for
systemd and related packages. The differences between testing and
unstable at any given time are so massive due to things like the
kernel having a fast development and upload cycle with lots of point
releases, a one line difference in one text file seems extremely minor
compared to the mountain of other things that are ongoing at any given
time. For example, right now literally everything is broken and has
been for months due to a kernel bug that makes it impossible to do
autopkgtest with a qemu guest. Do you have any specific indication for
this exact use case of t-p-u, rather than the generic issues with
t-p-u, that you cou

Bug#1077764: Ruling request on os-release specification implementation

[Sebastian Ramacher]

On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> Hi
> 
> On 03-08-2024 11:58, Luca Boccassi wrote:
> > > On the use of tpu:
> > > Personally, until now I fail to see enough value of being able to
> > > distinguish unstable and testing to give the package carrying
> > > /etc/os-release a permanent exception via tpu.
> > 
> > Thanks for chiming in - assuming for a moment that it is decided that
> > the change will be implemented, do you see any technical obstacles in
> > using t-p-u as proposed?
> 
> The biggest reason I know against using tpu is that it currently isn't
> receiving the same amount of testing (be it automatic (autopkgtest,
> piuparts, in the future reproducibility) or human) as unstable-to-testing
> migrations receive. For the automatic part, that's obviously a solvable
> problem (and already on my todo list for YEARS), but currently not the case.
> It also *always* requires human intervention by the Release Team. Another
> issue issue with tpu is that binNMU'ing is more difficult (I assume that's
> probably not very often relevant in the current case). I recall there are
> more issues with tpu, but I have forgotten them. When I find them, I'll add
> them.

To add to that: tpu is used for exceptional cases only. Cases where we
deem the result of the upload more important than the additional
work required of a release team member. Cases where we deem RC bugs
potentially introduced by missing QA for tpu uploads less severe than
the issue we are trying to fix in testing. Essentially, if it is not a
critical bug (think xz incident critical), going through tpu during non-freeze
time never happens.

For a package that is part of the essential set, having all the QA tools
checking the consequences of the inclusion of this a package is really
essential. Skipping out on QA checks for an essential packages that
would normally run for typical unstable to testing migration puts even
more pressure on the release team to make sure that accepting the
package from tpu does not severly break testing.

(As side note: in essentially all cases where I handled tpu uploads
(that I remember) during non-freeze time, it was more effort to untangle
unstable so I have asked maintainers explicitly to perform tpu uploads.)


Also, we have been pushing to keep testing and unstable as close as
possible. Packages not migrating for some time are considered RC buggy
to reduce the difference and where Paaul is thankfully filing the
corresponding bugs. Going through tpu would essentially introduce a
package that is auto-RC buggy in the essential set with consequences: it
causes even more divergence for autopkgtests in testing (reference
tests), in testing + pinned packages from unstable for migration checks
and in unstable. That would cause potentially even more work (for the RT
and maintainers) to figure out why some test is failing in one
configuration and not the other.


But keeping all of that aside, I don't see any label that could be
included as a static file in a package that would be correct due to the
duality of testing. trixie is defined by what we release on release day.
Labelling it trixie before that would be wrong as there are cases where
creating a "trixie" image before release will not end up with a trixie
image as produced after the release (just install something that is
later removed from testing). It would be labelled incorrectly as trixie
if users created it with testing or as testing + unstable. Any users may
add experimental to the mix as testing + sid + experimental which would
also be mislabelled.

Without checking the apt configuration (including the
Default-Release setting) and its sources configuration, there are always
cases where the label is incorrect during our typical release process
(and even then priorities may make it impossible to label properly).
Labelling testing as $selected_release_name/sid is a good enough
and more importantly an established compromise to label what will
become the next release up to the freeze.

So far I do not see a good enough reason to side-step typical migration
flow from unstable to testing for a label for testing that won't be
correct for one or another use case.

Cheers
-- 
Sebastian Ramacher

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 11:20, Paul Gevers  wrote:
>
> Hi
>
> On 03-08-2024 11:58, Luca Boccassi wrote:
> >> On the use of tpu:
> >> Personally, until now I fail to see enough value of being able to
> >> distinguish unstable and testing to give the package carrying
> >> /etc/os-release a permanent exception via tpu.
> >
> > Thanks for chiming in - assuming for a moment that it is decided that
> > the change will be implemented, do you see any technical obstacles in
> > using t-p-u as proposed?
>
> The biggest reason I know against using tpu is that it currently isn't
> receiving the same amount of testing (be it automatic (autopkgtest,
> piuparts, in the future reproducibility) or human) as
> unstable-to-testing migrations receive. For the automatic part, that's
> obviously a solvable problem (and already on my todo list for YEARS),
> but currently not the case. It also *always* requires human intervention
> by the Release Team. Another issue issue with tpu is that binNMU'ing is
> more difficult (I assume that's probably not very often relevant in the
> current case). I recall there are more issues with tpu, but I have
> forgotten them. When I find them, I'll add them.

Thank you. For this particular case: there would be 2 uploads for
every cycle, one at the end to add version numbers (this already
happens, no?), one at the beginning to change the VERSION_CODENAME. I
think from the point of view of requiring manual labour it should be
pretty lightweight compared to the current workload of managing
stable-p-u, at 2 uploads to review once every ~2 years, right?

For the binNMU side, this would be an Architecture: all package, so it
doesn't apply I think, right? It wouldn't be subject to any binary
transition for library bumps or things like that. In the current
proposal I am putting forward it's a binary arch: all with a single
fixed arch-independent text file in /usr/lib/ and a single fixed
symlink in /etc/ to the file in /usr/lib, no maintainer scripts
whatsoever, no dependencies.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 21:06, Sam Hartman  wrote:
>
> > "Luca" == Luca Boccassi  writes:
>
> Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
> >>
> >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> >> > To further clarify why the status quo with
> >> VERSION_CODENAME=trixie in > sid is really bad: it used to be
> >> that if you had "debian" mentioned in > os-release but no other
> >> version identifying fields, you knew you were > on testing OR
> >> unstable and you'd have to deploy horrendous hacks to > attempt
> >> and figure out which of the two it was really.
> >>
> >> OK, I think this is progress:
> >>
> >> What is the scenario / use-case in which it becomes necessary to
> >> distinguish between those two suites?
> >>
> >> To put that another way, what external piece of software needs to
> >> change its behaviour, dependent on whether you are running
> >> testing (of an unspecified datestamp) or unstable (of an
> >> unspecified datestamp)?
> >>
> >> Or perhaps you are thinking of a scenario in which a *person*
> >> needs to change their behaviour, dependent on whether they are
> >> running testing or unstable?
>
> Luca> Are the examples I provided at:
>
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
> Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5
>
> Not to me.
> I read what I think is the examples you linked from both bug reports.
> I didn't dig too far into the github links you provided though.
> What I see from your mail is that people want to distinguish unstable
> from testing and have created various hacks to do so.
>
> What I do not see is a compelling explanation of why Debian as a project
> wants to encourage that distinction.
> I agree that people doing a thing is evidence that it has value to those
> people.
> But I do not think you provided an explanation of what that value is.
>
> If it were easy to distinguish testing from unstable, why would I want
> to do that?

I don't see any of this being about "encouraging", because, as
mentioned in a previous mail, this is already how things work, and it
doesn't need any encouraging. It's about simply recognizing that this
is how everything already works, and changing 5 characters in a text
file that will have no repercussion on how these are used. Because
once again, I can do:

debootstrap trixie foo
debootstrap sid bar

foo and bar are different images, with different policies and
different lifecycles.
foo is currently in development, will freeze and then become stable
and security supported, and then move to LTS, and then be EOL. It is a
development-to-stable-to-eol image.
bar will continue being a development image, will never freeze, will
never become security supported, will never become LTS, will never be
EOL. It is a rolling image.

These details are what os-release is about, if you read the spec,
there are tons of fields about lifecycle management of an image, with
support and so on.

I am not describing a proposal here, I am describing how things work
and have always worked.

If you are asking me _why_ other people use the above how they use
them, well, I don't know? Unfortunately I left my Cerebro helmet in my
other coat. What I can do is show that it happens, it's always
happened, and it will very likely continue to happen. And what I am
highlighting is that we are the only distro that makes it hard to do
it, and I am highlighting that a specification (that I am one of the
owners of) is implemented incorrectly since it says A is B. And I am
asking to fix it so that A says it's A instead, and B continues to say
it's B as it does today.

I can say why _I_ do it though: because I regularly build and manage
multiple images, and I can correctly identify all of them based on
standard distro-agnostic tooling, but not Debian unstable, which is
the _only_ exception that requires annoying kludges to be used.

Bug#1077764: Ruling request on os-release specification implementation

[Paul Gevers]

Hi

On 03-08-2024 11:58, Luca Boccassi wrote:

On the use of tpu:
Personally, until now I fail to see enough value of being able to
distinguish unstable and testing to give the package carrying
/etc/os-release a permanent exception via tpu.


Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?


The biggest reason I know against using tpu is that it currently isn't 
receiving the same amount of testing (be it automatic (autopkgtest, 
piuparts, in the future reproducibility) or human) as 
unstable-to-testing migrations receive. For the automatic part, that's 
obviously a solvable problem (and already on my todo list for YEARS), 
but currently not the case. It also *always* requires human intervention 
by the Release Team. Another issue issue with tpu is that binNMU'ing is 
more difficult (I assume that's probably not very often relevant in the 
current case). I recall there are more issues with tpu, but I have 
forgotten them. When I find them, I'll add them.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 10:51, Paul Gevers  wrote:
>
> Hi,
>
> [Release Team member hat on, but I only voice my opinion as a member].
>
> On the use of tpu:
> Personally, until now I fail to see enough value of being able to
> distinguish unstable and testing to give the package carrying
> /etc/os-release a permanent exception via tpu.

Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?

> On Debian version numbers:
> I my view we only assign version numbers the moment we release. You can
> see that reflected in the symlink layout of debian/dists and in the
> trixie/Release file.

Understood, thanks for providing that additional information - then as
mentioned in another reply, I am changing the request from what it was
originally stated in the initial email that opened the bug, and I do
not request that version numbers be added to testing. The
implementation I am then requesting to rule on is defined in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 and, in
practice, results only in a change to unstable, testing's content will
remain as it currently is, with no change at all.

Bug#1077764: Ruling request on os-release specification implementation

[Paul Gevers]

Hi,

[Release Team member hat on, but I only voice my opinion as a member].

On the use of tpu:
Personally, until now I fail to see enough value of being able to 
distinguish unstable and testing to give the package carrying 
/etc/os-release a permanent exception via tpu.


On Debian version numbers:
I my view we only assign version numbers the moment we release. You can 
see that reflected in the symlink layout of debian/dists and in the 
trixie/Release file.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Sat, 3 Aug 2024 at 05:23, Sean Whitton  wrote:
>
> Hello,
>
> Luca is the upstream maintainer of the specification, but whether and
> how the specification as published applies to Debian is not simply up to
> his assertion.

To be really really precise, what I asserted is that the
implementation is currently buggy in unstable, which is technically
correct. I then _ask_ for a ruling to change the implementation. As
already mentioned many times in other mails, one is perfectly allowed
to say "this bug should not be fixed", "this bug's severity is nil",
but not to say "this bug does not exist". To repeat the same example,
if os-release was a program asserting on the state, it would run
correctly on testing, and it would crash when run in unstable. One can
say it's wrong that it crashes and one wants the state to remain
as-is, but one can't say it doesn't crash, because it is a fact that
it does, not an opinion. Both of these things can happen at the same
time and be both true: the TC rules that the os-release file in
unstable will remain as-is, and os-release implementation in Debian is
buggy. A bug report can be closed by an upload that changes something,
or by a close+wontfix.

> The TC is being asked to override how Santiago has determined the
> specification applies to Debian.
> The Release Team's opinion is as relevant as Santiago's, I think.

Everybody is welcomed to chime in at any time, and I have already said
so on RT's IRC channel the other day just after opening this bug.
On the matter of formal ownership however, I want to highlight that,
as you can see in various replies detailing the precise technical
solution that could possibly be implemented, there are _no changes to
testing_ being proposed here, in case what you are worried about here
is ownership of testing and changes to it. The only change would be in
unstable, and as far as I understand (I might be wrong, please correct
me) RT owns testing and [old]stable, not unstable. If you want to
ensure the owner of the relevant area is directly involved, then
perhaps it's the FTP team that should be, since as far as I understand
they are the owners of unstable (might be wrong here too)? Again,
everyone's welcome to chime in at any time, just trying to clarify
who's responsible for what here.

> Here is how it seems to me:
>
>   - the specification applies cleanly to our stable releases, and we
> want to support it, so we ship the appropriate metadata
>
>   - it applies to testing during the later stages of the freeze, and
> indeed we ship correct metadata at that time
>
>   - it does not apply to testing the rest of the time, and it never
> applies to unstable.  We ship metadata, but only as a side-effect of
> our process for preparing stable releases.
>
> If this is right, then the goal should not be to ship correct metadata
> in testing and unstable, because that's impossible.
> The goal should simply be to make whatever we ship in testing and
> unstable relatively unobtrusive to users.

If I understand correctly what you mean by "apply" here, and you mean
in terms of the specification and what it is meant for, then as one of
the owners of the spec I can say with certainty that the spec applies
to testing and unstable, at any time. There is nothing incompatible
with the way testing and unstable exist, are created, handled,
maintained, used or anything else, and they are nothing "special"
compared to other distributions, other than in the fact that the spec
is not implemented correctly in unstable. There should not be any
doubt on any of this, solely from the point of view of what the
specification is for and what its goals are. One can of course
disagree on whether it should be implemented as such and where, which
is what is happening right now.
If you mean it in terms of what is currently implemented in Debian,
then that's also inaccurate: the spec is currently correctly
implemented in testing, where it says VERSION_CODENAME=trixie at all
times. It is incorrectly implemented in unstable, since also there it
says VERSION_CODENAME=trixie, which makes it buggy, as sid is
obviously not trixie, and that's the main change I am asking to
implement. I'll note again that it is perfectly ok to omit VERSION_ID
until release time, and in one of the replies I am clarifying that, if
there are reasons to leave it out, it is ok to do so, and I am not
asking the CTTE to overrule that.

Also, speaking as someone who has worked on image building tools for
many years, the current state is extremely intrusive for users, and
that's why I am trying to fix it.

> Possibly it's less obtrusive to always ship "trixie" in both testing and
> unstable, rather than the special "trixie/sid" value.  Or maybe not.
> Santiago doesn't think so; it would be good to hear why, in this bug.
>
> I'd also like to note, in response to Luca, that it's misleading to say
> that it's a frankendebian to have packages from sid installed on a
> testing system, because that's 

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

Luca is the upstream maintainer of the specification, but whether and
how the specification as published applies to Debian is not simply up to
his assertion.

The TC is being asked to override how Santiago has determined the
specification applies to Debian.
The Release Team's opinion is as relevant as Santiago's, I think.

Here is how it seems to me:

  - the specification applies cleanly to our stable releases, and we
want to support it, so we ship the appropriate metadata

  - it applies to testing during the later stages of the freeze, and
indeed we ship correct metadata at that time

  - it does not apply to testing the rest of the time, and it never
applies to unstable.  We ship metadata, but only as a side-effect of
our process for preparing stable releases.

If this is right, then the goal should not be to ship correct metadata
in testing and unstable, because that's impossible.
The goal should simply be to make whatever we ship in testing and
unstable relatively unobtrusive to users.

Possibly it's less obtrusive to always ship "trixie" in both testing and
unstable, rather than the special "trixie/sid" value.  Or maybe not.
Santiago doesn't think so; it would be good to hear why, in this bug.

I'd also like to note, in response to Luca, that it's misleading to say
that it's a frankendebian to have packages from sid installed on a
testing system, because that's how testing and sid are meant to work.
It's only a frankendebian to have packages from different suites
installed on stable.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Sean Whitton]

Hello,

On Fri 02 Aug 2024 at 12:19pm +01, Luca Boccassi wrote:

> Sorry, but there's no other way to define this than a bug. Well, there
> are many more I could mention, but then Russ would whip out the cane
> ;-)

Russ is not the only person who finds interactions with you difficult.
Please don't trivialise his efforts to point you in a better direction
by comparisng them to punishment for schoolchildren.

-- 
Sean Whitton

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> 1) The os-release specification must be adhered to, and it must be
> possible to tell the difference between testing vs unstable, and each
> must be correctly identified by the respective metadata

Given the state of discussion, I think it is fairly evident that we do
not have consensus for the need to distinguish testing and unstable. We
have people arguing in favour and we have people arguing against that.
This is a point of disagreement.

> 2) Testing and unstable can continue to remain indistinguishable, and
> both be erroneously identified as trixie

Isn't there the third option of adhering to the os-release specification
without making testing and unstable distinguishable? I did not see this
ranked in your preference. Do you see it as even worse than the status
quo?

> Again you'll know better than me, but it seems to me rulings were made
> in the past that were along similar lines (eg: usrmerge) - there
> wasn't reviewable code there, no?

I think /usr-merge was quite different. The usrmerge package existed for
a long time before things to to the CTTE. The changes to debootstrap
were uploaded before things escalated to the CTTE another time and what
remained was basically a question of what defaults debootstrap should
have. In the case of os-release, the disagreement reached CTTE before
actual changes to the disputed status quo have been uploaded to unstable
and the available solution space is wider. Also the transition cost is
lower.

Keep in mind that our constitution says that you cannot be asked to work
(2.1) and in particular the CTTE cannot request work to be done either.
Instead, it can authorize a solution and require that developers do not
work against the chosen solution. Furthermore, the CTTE should select
among designs that have been proposed and "reasonably thoroughly
discussed" (6.3.5).  My perception is that your initial filing did not
meet this bar, but you later clarified your design and discussion is
ongoing.

> Sorry but I do not think that is an accurate representation. First of
> all, the implementation of the spec is bugged, period - it's not about
> being pedantic about it, it's about being completely incompatible: sid
> is identified as trixie, and that is just plain wrong, and there's no
> room for interpretation, no matter how one might try to bend it. You
> might say that you don't _care_ that the implementation is buggy, you
> might even say that it is worth, nay _good_ it to leave it buggy - but
> buggy it is, if I create a sid image, it will never in a million years
> be trixie, and yet it says it's trixie.

I think it has become abundantly clear that your view on this does not
represent consensus of discussion participants. It is not as black and
white as you paint it. Simon compared unstable to Ubuntu's proposed
pocket. It also happens that testing and unstable share the same pool
hierarchy and the vast majority of packages. On the other hand, Devuan
operates as an overlay repository to be added on top of a Debian
repository. I don't think it matters that Ubuntu's proposed is
implemented as a partial distribution overlaid onto another as that's
what other derivatives (that do update their os-release file) do as
well.

It would help if you could stop dismissing other people's views and
respectfully disagree with their views instead. Refer to Simon's reply
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#118 for more
details on this aspect.

> Secondly, I am not even sure what these conflicting requirements
> actually are? Could you please spell them out? If trixie was
> identified as trixie, and sid was identified as unstable, what
> compromise would be, er, compromised, precisely? Because the only
> practical objections I could find were based on the idea that
> implementations would be ugly or hard to maintain or so - as already
> mentioned, I am happy to relieve anybody else and take that hard and
> ugly maintenance burden for myself. What other actual problem would
> suddenly appear? What feature or advantage do we leave behind? How are
> things made worse for our users?

The devil is in the detail. Debian currently does not provide a simple
way to distinguish testing and unstable. As a result, some users have
opted to not rely on such differentiation and instead inspect particular
package versions for the features they are interested in. Others have
implemented heuristics to somehow tell testing and unstable apart as
they saw a need for doing so (that I still fail to see at this time).
Whilst you and others have presented code for telling testing and
unstable apart in multiple places, I am still having a hard time
figuring out why we had to tell them apart and in what way code would
behave differently for one or the other. If Debian were to differentiate
testing and unstable in a simple way, people would start relying on
that. That in turn (as laid out by Russ and Simon) would degr

Bug#1077764: Ruling request on os-release specification implementation

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
>> 
>> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
>> > To further clarify why the status quo with
>> VERSION_CODENAME=trixie in > sid is really bad: it used to be
>> that if you had "debian" mentioned in > os-release but no other
>> version identifying fields, you knew you were > on testing OR
>> unstable and you'd have to deploy horrendous hacks to > attempt
>> and figure out which of the two it was really.
>> 
>> OK, I think this is progress:
>> 
>> What is the scenario / use-case in which it becomes necessary to
>> distinguish between those two suites?
>> 
>> To put that another way, what external piece of software needs to
>> change its behaviour, dependent on whether you are running
>> testing (of an unspecified datestamp) or unstable (of an
>> unspecified datestamp)?
>> 
>> Or perhaps you are thinking of a scenario in which a *person*
>> needs to change their behaviour, dependent on whether they are
>> running testing or unstable?

Luca> Are the examples I provided at:

Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

Not to me.
I read what I think is the examples you linked from both bug reports.
I didn't dig too far into the github links you provided though.
What I see from your mail is that people want to distinguish unstable
from testing and have created various hacks to do so.

What I do not see is a compelling explanation of why Debian as a project
wants to encourage that distinction.
I agree that people doing a thing is evidence that it has value to those
people.
But I do not think you provided an explanation of what that value is.

If it were easy to distinguish testing from unstable, why would I want
to do that?

--Sam

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 18:01, Russ Allbery  wrote:
>
> Simon McVittie  writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi  writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>> updates or point releases. A release as in, Debian Bookworm, or Fedora
> >>> 40, or Ubuntu Noble, and so on.
>
> >> Why would you not want to identify point releases?  This really
> >> surprises me.
>
> > I think the idea is that two releases have a different VERSION_ID if and
> > only if they can both be fully up to date, but still remain
> > different. If we make the analogy of git, VERSION_ID labels a branch,
> > not a tag.
>
> Oh, thank you, this was not at all obvious to me.  If this is indeed the
> case, that would be a useful clarification to add to the specification.
>
> This also explains the desire to identify testing as trixie, but not
> identify unstable as trixie.  If one configures a testing system to point
> to trixie, then fully updating it will move it into the stable release
> when the stable release comes out.  However, if one points a system at
> unstable, that system will never become a trixie system and will always
> continue to point to a different release.
>
> This is not an entirely clean analogy, since it's also possible to point a
> system at the testing suite directly, rather than using the code name, in
> which case that system will also never become trixie.  So in that sense
> testing is simultaneously both trixie and not trixie depending on exactly
> how you configure apt.
>
> This sort of ambiguity is, I think, part of why this proposal generates so
> much discussion.  Debian simply doesn't currently have clean semantics for
> testing.  It exists in a sort of quantum superposition where it is
> multiple things simultaneously for different people, and this proposal is
> trying to label it in a way that collapses that state to match the mental
> model of one group of people, invalidating the mental model of a different
> group of people.

If you instantiate it as 'testing', using that keyword through your
configuration, including apt, then it will be updated to the next
version when that is created in the archive. So it is still trixie
today, and tomorrow it will be forky, and everything, including the
os-release file, will be updated accordingly with my proposal.

>From the point of view of the os-release specification, this is
exactly the same as using 'stable' to build and manage an image. Today
that is bookworm, yesterday it was buster, tomorrow it will be trixie.
It is still correct that today os-release says it's bookworm. Once it
is upgraded, the os-release will be upgraded too and say 'trixie'
because that's released and that's what the 'stable' alias points to.
It's the same installation, and it gets upgraded to a new release -
that's entirely supported by the os-release spec. That's the same if
you are tracking 'testing'. And that is why in my very first mail at
the top of this bug, I said that testing is _not_ a rolling release,
because there's a -1 and a +1 and it has a limited lifespan. Support
status is different than stable, but there are other fields to
indicate that, and again it applies just as well to oldoldoldstable.

So again, while I see why there could be different points of views and
some confusion around what means what, my view is that this proposal
doesn't really introduce anything new, and doesn't change anything
that happens today in any fundamental way. As already mentioned, I do
not see anything fundamentally incompatible between the os-release
concept and the unstable or testing concepts as they are today,
whether they are considered with their codenames or the aliases.

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Simon McVittie  writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi  writes:

>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>> 40, or Ubuntu Noble, and so on.

>> Why would you not want to identify point releases?  This really
>> surprises me.

> I think the idea is that two releases have a different VERSION_ID if and
> only if they can both be fully up to date, but still remain
> different. If we make the analogy of git, VERSION_ID labels a branch,
> not a tag.

Oh, thank you, this was not at all obvious to me.  If this is indeed the
case, that would be a useful clarification to add to the specification.

This also explains the desire to identify testing as trixie, but not
identify unstable as trixie.  If one configures a testing system to point
to trixie, then fully updating it will move it into the stable release
when the stable release comes out.  However, if one points a system at
unstable, that system will never become a trixie system and will always
continue to point to a different release.

This is not an entirely clean analogy, since it's also possible to point a
system at the testing suite directly, rather than using the code name, in
which case that system will also never become trixie.  So in that sense
testing is simultaneously both trixie and not trixie depending on exactly
how you configure apt.

This sort of ambiguity is, I think, part of why this proposal generates so
much discussion.  Debian simply doesn't currently have clean semantics for
testing.  It exists in a sort of quantum superposition where it is
multiple things simultaneously for different people, and this proposal is
trying to label it in a way that collapses that state to match the mental
model of one group of people, invalidating the mental model of a different
group of people.

-- 
Russ Allbery (r...@debian.org)  

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 17:07, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That's yet another Debian-specific workaround. The point of this is,
> > again, answering the question "what is this vendor tree" _without_
> > distro specific kludges. That's the entire reason for os-release to
> > exist. If the answer at any point is "check os-release AND THEN run this
> > distro specific set of scripts or binaries", then the answer is wrong,
> > and the implementation of the spec is buggy. Again, one might say "I am
> > ok with this being buggy because we gain X Y and Z in exchange", but
> > buggy it is and buggy it will remain.
>
> This talk about "buggy" and "workarounds" didn't help me understand what
> you meant, but I think what you're saying is that I'm right, you *do* only
> care about the apt configuration, BUT apt is Debian-specific and figuring
> out how it is configured is not something that can be done portably, so
> you do want to use os-release as a proxy for that information because it's
> a cross-distro tool.
>
> That makes sense to me.  It's a fallible proxy and it will get a bunch of
> edge cases wrong, but it's probably not possible to do better with an
> equivalently simple tool.

Right, but one important correction though - it's not _only_ apt, it's
_also_ apt. Apt is one of the common issues, yes, but it's not the
only one. It is entirely valid to create an OS vendor tree without apt
or its configuration, for a minimal read-only image deployment for a
VM or a container, that you update with an image-based tool with A/B
style partitioning, for example. How do you identify such a vendor
tree? There's no apt. The answer on every other distro is: read
usr/lib/os-release. In Debian it's: read os-release and pray the old
gods and the new that it returns something identifiable, and otherwise
just despair and take a wild guess.

> Fundamentally, you want to change Debian's policy about testing to
> complete the separation from unstable and treat it as a first-class
> release in its own right in our metadata.  Debian has historically not
> done this and generally discouraged people from doing this (this is *not*
> just Santiago's position; Santiago is correctly reflecting the previous
> consensus of the project), but there's always been a fair bit of
> controversy over that point, and I personally tend towards the side that
> thinks testing can be usefully treated as a rolling release with very
> substantial caveats and limitations.
>
> I do agree that it's often useful to be able to quickly determine if an
> image is pointing to testing or to unstable.

I see what you are saying, but I have to say that expressing it like
that makes it sound like I am asking to flip the thing on its head
completely, and do something new and unprecedented, but I'm really
not? I am asking to add one line to a text file. I'm not asking to
change a policy. Nothing else will change - all workflows, all usages,
all intentions, all procedures, all tools, everything will be exactly
the same before and after. Because you can already, today, build and
install a testing image, run it, update it, manage it, use it for
workloads, and never, ever get even a hint that something called
"unstable" even exists. We know this happens, and it always has
happened, and it will continue to happen. And the same is true for
unstable. They each have their own section of the archive, which are
independent from each other and fully complete on their own (as
opposed to other things already mentioned like ubuntu-proposed or
experimental or stable-proposed-updates). You can do 'debootstrap
unstable' build an image and run it, you can do 'debootstrap trixie'
build an image and run it, and you were always able to do so. So, I
don't know, it seems excessive and scary to say it's a change in
policy? No policy changes here, no?

> > On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:
>
> >> Well, it's related to your example of the zoom package basing decisions
> >> on the version number.  If they had done that based on a version number
> >> of testing, there's a fairly high chance that whatever decisions they
> >> made would be wrong by the time the stable release happens,
> >> particularly if they do that early in a release cycle.
>
> >> That said, I would expect most third-party non-free packages like that
> >> to not care at all about anything in Debian until it reached stable, so
> >> the chances of them doing that may be low.
>
> > Uh, I did not provide an example regarding zoom? Where's that from?
>
> Ugh, I'm sorry, I was reading a lot of bug history and completely
> misattributed that message (and, for that matter, when it was sent).  I
> was thinking of:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91
>
> which was from Kipp Cannon.  My apologies for the confusion.

Right, I can see things like that happening - that's both a symptom of
a bug in zoom and a bug in Debian. It's a bug in zoom because
VERSION_ID is not mandat

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> > It is correct as-is. VERSION_ID is meant to identify a release, not
> > updates or point releases. A release as in, Debian Bookworm, or Fedora
> > 40, or Ubuntu Noble, and so on.
> 
> Why would you not want to identify point releases?  This really surprises
> me.

I think the idea is that two releases have a different VERSION_ID if and
only if they can both be fully up to date, but still remain different. If
we make the analogy of git, VERSION_ID labels a branch, not a tag.

If Debian 12 is like a git branch (and unstable is like git main),
then Debian 12.0 and 12.6 are more like tags on the Debian 12 branch.
Debian 12 is still maintained and changing, but Debian 12.6 was a point
in time, it already happened, and now it's never going to change.

So, 11 vs. 12 vs. 13 are different VERSION_IDs, because a fully updated
Debian 11 is not the same as a fully updated Debian 12 or 13.

But 12.5 vs. 12.6 don't have different VERSION_IDs, because if you upgrade
Debian 12.5, it *becomes* 12.6: there is no separate 12.5.x branch that
anyone is maintaining as something distinct from 12.6.

(It might make sense for there to be a defined field in os-release for
"what's the most recent point release we've caught up with?" *as well*,
but VERSION_ID is not that.)

smcv

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  writes:

> That's yet another Debian-specific workaround. The point of this is,
> again, answering the question "what is this vendor tree" _without_
> distro specific kludges. That's the entire reason for os-release to
> exist. If the answer at any point is "check os-release AND THEN run this
> distro specific set of scripts or binaries", then the answer is wrong,
> and the implementation of the spec is buggy. Again, one might say "I am
> ok with this being buggy because we gain X Y and Z in exchange", but
> buggy it is and buggy it will remain.

This talk about "buggy" and "workarounds" didn't help me understand what
you meant, but I think what you're saying is that I'm right, you *do* only
care about the apt configuration, BUT apt is Debian-specific and figuring
out how it is configured is not something that can be done portably, so
you do want to use os-release as a proxy for that information because it's
a cross-distro tool.

That makes sense to me.  It's a fallible proxy and it will get a bunch of
edge cases wrong, but it's probably not possible to do better with an
equivalently simple tool.

Fundamentally, you want to change Debian's policy about testing to
complete the separation from unstable and treat it as a first-class
release in its own right in our metadata.  Debian has historically not
done this and generally discouraged people from doing this (this is *not*
just Santiago's position; Santiago is correctly reflecting the previous
consensus of the project), but there's always been a fair bit of
controversy over that point, and I personally tend towards the side that
thinks testing can be usefully treated as a rolling release with very
substantial caveats and limitations.

I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.

> On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:

>> Well, it's related to your example of the zoom package basing decisions
>> on the version number.  If they had done that based on a version number
>> of testing, there's a fairly high chance that whatever decisions they
>> made would be wrong by the time the stable release happens,
>> particularly if they do that early in a release cycle.

>> That said, I would expect most third-party non-free packages like that
>> to not care at all about anything in Debian until it reached stable, so
>> the chances of them doing that may be low.

> Uh, I did not provide an example regarding zoom? Where's that from?

Ugh, I'm sorry, I was reading a lot of bug history and completely
misattributed that message (and, for that matter, when it was sent).  I
was thinking of:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91

which was from Kipp Cannon.  My apologies for the confusion.

>> I am surprised that point releases don't change VERSION_ID, and now I'm
>> curious why that's the case.  I was assuming, having not previously
>> looked at it, that VERSION_ID would match /etc/debian_release, but I
>> see that it doesn't and has only the major version.

> It is correct as-is. VERSION_ID is meant to identify a release, not
> updates or point releases. A release as in, Debian Bookworm, or Fedora
> 40, or Ubuntu Noble, and so on.

Why would you not want to identify point releases?  This really surprises
me.

>> Regardless, security uploads do potentially create this problem, but we
>> also try pretty hard to not change major functionality in security
>> uploads in ways that may prompt someone to want to change behavior
>> based on that version.  There is a window of possibility there, I think
>> it's sufficiently narrow to not worry that much about.  It's at least a
>> much narrower problem than version numbers in testing.

> See other mail. It is really not narrow at all, because of kernel
> upstream LTS updates. The upstream kernel quality of these branches is
> really, really low, and massive regressions sneak in at all times. The
> difference of behaviour between point releases is huge.

I believe kernels are usually (not always, but usually) updated as part of
point releases, which is yet another reason why I am so baffled as to why
the VERSION_ID would not track point releases.

> Debian stable updates do not, and pretty much never have, include only
> security fixes.

Exactly, which is why they should result in a VERSION_ID bump.

-- 
Russ Allbery (r...@debian.org)  

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne 
wrote:
> Hi Russ,
> 
> Let me adress the essential/bootstrap aspects of this sub-discussion
> only.
> 
> On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> > Given that it's included in base-files now and base-files is
essential, I
> > believe it has to continue to be provided by an essential package,
unless
> > we want to try to do the work of figuring out if os-release can be
removed
> > from essential (and I would not be eager to do that).
> 
> I concur.
> 
> > Since it is part of the essential set, though, I'm not sure the
dependency
> > from base-files is actually needed (but also it may not really
matter).  I
> > think dependencies between essential packages are only really used
during
> > the bootstrapping phase, and presumably os-release is not needed by
> > bootstrapping.
> 
> It actually is the other way round. debootstrap-like tools will
> automatically pick up all packages marked with "Essential: yes".
> Bootstrapped systems will not magically install newly essential
packages
> though. So doing an upload of base-files that releases /etc/os-
release
> will not magically cause a newly essential os-release package to be
> installed and thus our essential promise of /etc/os-release may be
> temporarily broken. (There is no implication of how bad breaking this
> promise is.) So whenever we want to add a new package to the
essential
> set, we need some existing essential package to declare a dependency
on
> that new package for the duration of one release cycle (as we do not
> support skip upgrades).
> 
> The obvious candidate to express such a dependency would be base-
files
> here and that brings us back to the aspects you (Russ) mentioned
earlier
> regarding the fragility of the bootstrap order related to base-files.
> Admittedly, bootstrapping is more empirically solved in Debian than
> well-defined. As I attempted clarifying this in Debian policy
earlier,
> the outcome was to explicitly leave it undefined. If I remember
> correctly, randomly ordering the maintainer scripts executed during
> filesystem bootstrap makes things fail every now and then and the
order
> that most tools produce works well enough currently.  Any new
dependency
> inside the essential set poses a risk of perturbing this order that
> happens to work by chance. Hence my request to validate the proposed
> changes.  With luck, things just work, but we better figure out
before
> we upload to unstable.
> 
> This is not pretty, but it is what we have. And then I see this
mostly
> as a work item rather than a blocking issue once we agree on the
other
> matters.

Validating is of course necessary. If the worry is around changing the
dependencies of base-files, I would be happy to carry the dependency on
a new os-release binary package in init-system-helpers, which is
already Essential: yes. I already did something similar in Bookworm to
force all installations to become usrmerged, and I do not recall issues
with the bootstrapping order. This would be even easier in practice as
the new package would have a single file, no maintainer scripts, no
dependencies and no build dependencies. Would that solve your concerns?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
>
> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> > To further clarify why the status quo with VERSION_CODENAME=trixie in
> > sid is really bad: it used to be that if you had "debian" mentioned in
> > os-release but no other version identifying fields, you knew you were
> > on testing OR unstable and you'd have to deploy horrendous hacks to
> > attempt and figure out which of the two it was really.
>
> OK, I think this is progress:
>
> What is the scenario / use-case in which it becomes necessary to
> distinguish between those two suites?
>
> To put that another way, what external piece of software needs to
> change its behaviour, dependent on whether you are running testing
> (of an unspecified datestamp) or unstable (of an unspecified datestamp)?
>
> Or perhaps you are thinking of a scenario in which a *person* needs to
> change their behaviour, dependent on whether they are running testing
> or unstable?

Are the examples I provided at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

enough to answer this question? (I'm trying to avoid copy/pasting the
same stuff multiple times in an already long and
probably-going-to-be-even-longer thread)

> > Sorry, but there's no other way to define this than a bug.
>
> I would personally characterize it as a potential root cause for bugs,
> more than as a bug itself. To me, an example of one of those bugs might
> look more like "I run ansible/Puppet/etc. against my test VM, and I
> expect it to do a useful thing, but actually it..." (with the buggy result
> perhaps being to crash, or to install the wrong package, or something).

It's not running code, but we consider mistakes in documentation bugs
too, and treat them as such in our tools and processes. A wrong
implementation of a specification, that results in wrong text being
published, should still qualify as a bug given precedents, even if
it's not in itself running code. It might or might not cause other
bugs/bad behaviour, but that should be orthogonal.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 12:48, Simon McVittie  wrote:
>
> On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> > VERSION_CODENAME=trixie was added, and the problem as explained is
> > that it's present in sid too. So the only identifier we have in sid,
> > identifies it as trixie, which is categorically and unequivocally
> > wrong.
>
> When involved in a disagreement, please could you try to make an effort
> to understand the point of view of the other side, rather than declaring
> them to be categorically and unequivocally wrong? I think that would
> lead to fewer people feeling that they're being shouted at and refusing
> to engage with you, which is likely to result in more of the changes
> you want to see actually being adopted.

Some things are viewpoints, and then there are such things as facts.
As mentioned in another mail, one is of course allowed to say "it is
fine if the os-release implementation in debian is buggy". One can say
"the severity of this bug is nil". One can say "it is better if the
bug is not solved". One doesn't even have to state a reason for such a
belief, and it's perfectly valid nonetheless. That's a viewpoint.
It is not a "viewpoint" to say "the os-release implementation in
debian is not buggy", because it's not a competing opinion or design
choice, it's denying a fact that exists independently of opinions, for
reasons already explained at length, that I am not going to repeat yet
again. One can disagree on the severity of the bug and think it is
nil, one can disagree on whether it should be fixed or how. It is
still a bug. Why is it a problem to define it as such? Why is saying
"the spec says A, this does B, therefore it's a bug" equivalent to
"shouting" or "insulting"? If this was a running program and it
checked the state according to the spec and assert on it, it would
crash. Whether one holds the view that it would be right or wrong to
crash, it would still crash, and there's no point in denying it would,
and I don't see how it helps with resolving anything or making any
progress.

> In this case, I think the two design principles might be:
>
> - you think of sid as an independent rolling-release distribution in
>   its own right, an alternative to e.g. Arch Linux, and so you want to
>   label sid images/containers/chroots/etc. in a way that is consistent
>   with that point of view;

I don't think that's accurate. It's not an opinion that one can run
"debootstrap sid", install it, run it, and never ever reach any point
in time where that is a stable, security supported os vendor tree that
will go EOL and have a version+1. This is a fact. We know for a fact
that this happens, today, yesterday and tomorrow, in the real world.
It is also a fact that due to this, the os-release specification
mandates certain things to be defined in its metadata, that are
currently not done today, and that some that are done, shouldn't.

It is an opinion that I think this should be fixed, and it is also an
opinion that fixing it is more important than other competing
concerns. It is an opinion to say that it is better to leave it as-is.

> - Santiago thinks of sid as a tool to be used as part of the process of
>   making our next stable release, an alternative to e.g. Fedora Rawhide,
>   and wants to label sid images/etc. in a way that is consistent with
>   *that* point of view

That's not an opinion either. It is a fact that sid is a tool used to
develop the next stable release. I recognize that fact, and I do not
want to change it.

My understanding is that Santiago's opinion is that fact is a reason
enough to avoid fixing the above issue, because labeling is
incompatible with , and because sid and trixie must remain
undistinguishable because they are the same thing. It is my opinion
that labeling does not impede on the goal of sid being a tool to
develop the next stable release, and it is a fact that the os-release
specification is not incompatible with this situation, and it is my
opinion that we should change this implementation, and it is my
opinion that it would not negatively affect sid's purpose and role in
our development model, and it is my opinion that trixie and sid should
be distinguishable, and it is a fact that trixie and sid being
distinguishable would fix a bug in the os-release implementation.

> I think that, as a project, we need a lot more willingness to frame
> disagreements in terms of "I see your point, but I think my point is
> more important", and a lot less "you're just wrong". All of us are
> doing our best to make Debian the best possible Free operating system,
> even if we don't always agree on precisely what that means.

I don't see saying "this is a bug" as "I don't see your point" or "you
are just wrong". I see it as stating a fact. This is my opinion on it
being a fact and not an opinio... ok I am getting entangled now. The
point of saying "this is a bug" is to clarify what is an opinion and
what isn't, without having to pedantically pre-label everyt

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> To further clarify why the status quo with VERSION_CODENAME=trixie in
> sid is really bad: it used to be that if you had "debian" mentioned in
> os-release but no other version identifying fields, you knew you were
> on testing OR unstable and you'd have to deploy horrendous hacks to
> attempt and figure out which of the two it was really.

OK, I think this is progress:

What is the scenario / use-case in which it becomes necessary to
distinguish between those two suites?

To put that another way, what external piece of software needs to
change its behaviour, dependent on whether you are running testing
(of an unspecified datestamp) or unstable (of an unspecified datestamp)?

Or perhaps you are thinking of a scenario in which a *person* needs to
change their behaviour, dependent on whether they are running testing
or unstable?

> Sorry, but there's no other way to define this than a bug.

I would personally characterize it as a potential root cause for bugs,
more than as a bug itself. To me, an example of one of those bugs might
look more like "I run ansible/Puppet/etc. against my test VM, and I
expect it to do a useful thing, but actually it..." (with the buggy result
perhaps being to crash, or to install the wrong package, or something).

smcv

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> VERSION_CODENAME=trixie was added, and the problem as explained is
> that it's present in sid too. So the only identifier we have in sid,
> identifies it as trixie, which is categorically and unequivocally
> wrong.

When involved in a disagreement, please could you try to make an effort
to understand the point of view of the other side, rather than declaring
them to be categorically and unequivocally wrong? I think that would
lead to fewer people feeling that they're being shouted at and refusing
to engage with you, which is likely to result in more of the changes
you want to see actually being adopted.

Dismissing the other side's point of view as "just wrong" is a pattern
that I keep seeing in Debian, from multiple people, and frankly it's
exhausting. Even when I completely agree with you about the technical
content of what you're saying, it makes every disagreement into an
unpleasant interaction that drains my energy and motivation, and I know
that I'm not the only DD who is put off by the way relatively minor
disagreements escalate.

Normally when there's a non-obvious technical decision to be made,
"both sides" have a valid design principle that they're trying to follow,
and the essence of the decision is a value-judgement about which of the
two contradictory design principles is more important than the other
one (better cost/benefit ratio, defining cost as broadly as possible).
These are decisions that we need to make, but they shouldn't be a fight:
sometimes we have to agree to disagree, and sometimes we have to accept
that our reasons to want option A are outweighed by someone else's
reasons to want option B.

In this case, I think the two design principles might be:

- you think of sid as an independent rolling-release distribution in
  its own right, an alternative to e.g. Arch Linux, and so you want to
  label sid images/containers/chroots/etc. in a way that is consistent
  with that point of view;

- Santiago thinks of sid as a tool to be used as part of the process of
  making our next stable release, an alternative to e.g. Fedora Rawhide,
  and wants to label sid images/etc. in a way that is consistent with
  *that* point of view

and each of you is arguing in favour of the metadata that makes most
sense when you start from that point of view?

Of course, the real answer to "is sid a rolling release distribution or
is it a tool for making the next stable?" is "yes", so neither of those
points of view is completely wrong, but neither of them is the whole
story either.

I think that, as a project, we need a lot more willingness to frame
disagreements in terms of "I see your point, but I think my point is
more important", and a lot less "you're just wrong". All of us are
doing our best to make Debian the best possible Free operating system,
even if we don't always agree on precisely what that means.

smcv
not a TC member

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 11:35, Luca Boccassi  wrote:
>
> On Fri, 2 Aug 2024 at 10:15, Simon McVittie  wrote:
> > So I think Luca really has two distinct change requests here, not just one:
> >
> > 1. Label testing as Debian 13 starting from the beginning of the trixie
> >cycle, and the equivalent for each future cycle
> > 2. Label unstable as something that differs from testing
> >
> > and it would be technically possible to have both, or neither, or accept
> > (1.) but reject (2.).
> >
> > I personally have a lot of sympathy for wanting (1.) - as I said, when
> > I'm communicating with developers outside the Debian bubble who don't
> > know our processes, I tend to refer to both testing and unstable as some
> > sort of prerelease, alpha or preview of Debian 13, because that's close
> > enough to true. I am much more hesitant about (2.), because testing and
> > unstable are more similar than they are different, and more similar to
> > each other than they are to their state 6 months ago.
>
> 1 is already the case, and actually I am asking to revert that.
> VERSION_CODENAME=trixie was added, and the problem as explained is
> that it's present in sid too. So the only identifier we have in sid,
> identifies it as trixie, which is categorically and unequivocally
> wrong.

To further clarify why the status quo with VERSION_CODENAME=trixie in
sid is really bad: it used to be that if you had "debian" mentioned in
os-release but no other version identifying fields, you knew you were
on testing OR unstable and you'd have to deploy horrendous hacks to
attempt and figure out which of the two it was really. But if you had
VERSION_CODENAME, you could just use that, full stop, and everything
was sane.

Now all these hacks have to be further hacked, and you have to check
if you are on Debian, and if you have VERSION_CODENAME, and if you do
_not_ have VERSION_ID _then_ you have to discard VERSION_CODENAME,
completely ignore it, and then run the previous hacks.

Sorry, but there's no other way to define this than a bug. Well, there
are many more I could mention, but then Russ would whip out the cane
;-)

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 11:39, Matthew Vernon  wrote:
>
> Hi,
>
> With my jaunty TC member hat on, I would prefer if issue came to us with
> a description of both sides' perspective on the discussion that they
> would view as fair. In any case, I hope that Santiago will feel able to
> chime in with their perspective.

In case that doesn't happen, for reference, his position is
articulated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021663#55
and the other linked bugs.

> My initial thought is that this is really about whether the base-files
> maintainer is correct to have decided that os-release for testing and
> unstable should not provide VERSION nor VERSION_ID; that seems to me the
> technical policy question, and whether os-release moves into a new
> package or not is an implementation detail that flows from that decision?

Almost, but not quite - as mentioned in other emails it's actually
fine to omit VERSION/VERSION_ID until release time. The main vector to
do this distinction is VERSION_CODENAME which is currently set to
'trixie' in both trixie and sid. I am asking the CTTE to rule that
testing and unstable must have different VERSION_CODENAME fields in
their respective os-release files, that is to say "trixie" and "sid"
respectively.

It is correct to say that "sid does not have a version", just like
Arch or Tumbleweed, so that is not a contentious point. It is
acceptable to me to say "trixie does not have a version until release
day", although I would prefer it did, because it is sufficient to have
VERSION_CODENAME being different for the purpose of this ticket.

Please note that older bugs against base-files mention version numbers
because VERSION_CODENAME is a later addition to the spec, it appeared
in 2016, so VERSION_ID used to be the only way to tell the difference
between releases programmatically, so naturally users reporting bugs
about being impossible to distinguish testing vs unstable asked for
that to be added. It's no longer the case today, so this request is
_not_ about overriding the decision to omit VERSION_ID until release
date.

> I think the submitter's contention against that is that in fact people
> do want to be able to differentiate between testing and unstable. I
> think they would go further and say that people want to be able to do
> this without doing anything more involved than inspecting
> /etc/os-release and that Debian should support them in so doing.

Yes, this is correct, minus the part about the specific field numeric
versions, which is more of a "nice to have" but can still be omitted
if, e.g., RT prefers doing so.

Bug#1077764: Ruling request on os-release specification implementation

[Matthew Vernon]

Hi,

With my jaunty TC member hat on, I would prefer if issue came to us with 
a description of both sides' perspective on the discussion that they 
would view as fair. In any case, I hope that Santiago will feel able to 
chime in with their perspective.


My initial thought is that this is really about whether the base-files 
maintainer is correct to have decided that os-release for testing and 
unstable should not provide VERSION nor VERSION_ID; that seems to me the 
technical policy question, and whether os-release moves into a new 
package or not is an implementation detail that flows from that decision?


I think the base-files maintainer's position is that testing and 
unstable do not have a version, and that testing gets a version towards 
the end of the release cycle (in closing #659853 they say "like 
/etc/debian_version, this file should only be considered meaningful for 
stable releases"). They assert that the release team supports this 
approach (and I've not seen any suggestion to the contrary).


I note that the os-release spec says "Note that operating system vendors 
may choose not to provide version information, for example to 
accommodate for rolling releases. In this case, VERSION and VERSION_ID 
may be unset. Applications should not rely on these fields to be set."


I think the submitter's contention against that is that in fact people 
do want to be able to differentiate between testing and unstable. I 
think they would go further and say that people want to be able to do 
this without doing anything more involved than inspecting 
/etc/os-release and that Debian should support them in so doing.


Is that a broadly fair summary?

Regards,

Matthew

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 10:15, Simon McVittie  wrote:
> The closest equivalent of what Fedora and Ubuntu do would be to label
> both testing and unstable as though they were some sort of Debian 13
> prerelease, but not distinguish between the two. But Luca is asking for
> unstable images/chroots/installations to be machine-readably different,
> even if they happen to contain all of the same packages at the same
> versions (other than base-files), and I think that's because unstable
> has more users than Ubuntu proposed, and is typically further away from
> testing than the gap between Ubuntu proposed and devel.

As far as I understand Ubuntu proposed is a partial pocket, like
stable-proposed-updates. It doesn't have full content at all times.
You cannot debootstrap and install oracular-proposed, you _have_ to
include oracular. So it's correctly not identified separately and
independently in its os-release, as it doesn't make sense to do so,
from the point of view of the os-release specification and its purpose
and intent. oracular-proposed will always be oracular, if you clone it
now and update it a year on it will still fetch oracular 24.10
content, not 25.04 . Debian sid will remain
debian sid forever, if you clone sid today and update it in 2 years
time you will not get trixie 13.x. If you clone testing today and
update it in 2 years time, you will get trixie 13.x. If you enable
bookworm-proposed-updates on bookworm, it's still bookworm. If you
enable experimental on sid, it's still sid.

Testing and unstable have completely separate and independent
archives, you can point an image builder to one OR the other, in
isolation, and it will produce a fully complete and runnable and
bootable OS tree. The fact that they might have some or even all
content in common at particular points in time is orthogonal and
unrelated to what the purpose of os-release is.

> So I think Luca really has two distinct change requests here, not just one:
>
> 1. Label testing as Debian 13 starting from the beginning of the trixie
>cycle, and the equivalent for each future cycle
> 2. Label unstable as something that differs from testing
>
> and it would be technically possible to have both, or neither, or accept
> (1.) but reject (2.).
>
> I personally have a lot of sympathy for wanting (1.) - as I said, when
> I'm communicating with developers outside the Debian bubble who don't
> know our processes, I tend to refer to both testing and unstable as some
> sort of prerelease, alpha or preview of Debian 13, because that's close
> enough to true. I am much more hesitant about (2.), because testing and
> unstable are more similar than they are different, and more similar to
> each other than they are to their state 6 months ago.

1 is already the case, and actually I am asking to revert that.
VERSION_CODENAME=trixie was added, and the problem as explained is
that it's present in sid too. So the only identifier we have in sid,
identifies it as trixie, which is categorically and unequivocally
wrong.

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Russ,

Let me adress the essential/bootstrap aspects of this sub-discussion
only.

On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> Given that it's included in base-files now and base-files is essential, I
> believe it has to continue to be provided by an essential package, unless
> we want to try to do the work of figuring out if os-release can be removed
> from essential (and I would not be eager to do that).

I concur.

> Since it is part of the essential set, though, I'm not sure the dependency
> from base-files is actually needed (but also it may not really matter).  I
> think dependencies between essential packages are only really used during
> the bootstrapping phase, and presumably os-release is not needed by
> bootstrapping.

It actually is the other way round. debootstrap-like tools will
automatically pick up all packages marked with "Essential: yes".
Bootstrapped systems will not magically install newly essential packages
though. So doing an upload of base-files that releases /etc/os-release
will not magically cause a newly essential os-release package to be
installed and thus our essential promise of /etc/os-release may be
temporarily broken. (There is no implication of how bad breaking this
promise is.) So whenever we want to add a new package to the essential
set, we need some existing essential package to declare a dependency on
that new package for the duration of one release cycle (as we do not
support skip upgrades).

The obvious candidate to express such a dependency would be base-files
here and that brings us back to the aspects you (Russ) mentioned earlier
regarding the fragility of the bootstrap order related to base-files.
Admittedly, bootstrapping is more empirically solved in Debian than
well-defined. As I attempted clarifying this in Debian policy earlier,
the outcome was to explicitly leave it undefined. If I remember
correctly, randomly ordering the maintainer scripts executed during
filesystem bootstrap makes things fail every now and then and the order
that most tools produce works well enough currently.  Any new dependency
inside the essential set poses a risk of perturbing this order that
happens to work by chance. Hence my request to validate the proposed
changes.  With luck, things just work, but we better figure out before
we upload to unstable.

This is not pretty, but it is what we have. And then I see this mostly
as a work item rather than a blocking issue once we agree on the other
matters.

Helmut

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 10:09, Simon McVittie  wrote:
>
> On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> > The second [objection from the base-files maintainer] is pushing forward a
> > philosophical explanation according to which testing and unstable are
> > not actually different images, but they are one and the same (two sides
> > of the same coin is the expression used). While that might be true in a
> > philosophical sense, this is a practical matter, and it concerns only
> > the os-release specification and its implementation. In such context,
> > testing and unstable are different and independent images, built from
> > different and independent archives of packages. For example, at any
> > point in time you can do:
> >
> > deboostrap testing /tmp/a
> > deboostrap unstable /tmp/b
> >
> > and if your shell history is lost, you have no reliable, stable,
> > distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
>
> But, let's continue your example: suppose you ran those commands back in
> January. Now, 6 months later, run similar commands again:
>
> debootstrap testing /tmp/c
> debootstrap unstable /tmp/d
>
> With your proposed labelling of testing and unstable as being fundamentally
> different, you would have:
>
> /tmp/a: testing from January, labelled as testing (or trixie or Debian 13)
> /tmp/b: unstable from January, labelled as unstable
> /tmp/c: testing from July, labelled as testing (or trixie or Debian 13)
> /tmp/d: unstable from July, labelled as unstable
>
> But, contrary to that, the differences between a and b will be relatively
> small, and so will the differences between c and d; whereas the differences
> between a and c will be large (even though they're both labelled as
> testing) and so will the differences between b and d.
>
> For example, a and b will have glibc 2.37, but c and d will have 2.39,
> with whatever behaviour changes have happened in the last 6 months.
> Similarly, neither a nor b has been through the t64 transition, but
> both c and d have.
>
> I think the most important fact about all of these chroots is
> "it's strictly newer than Debian 12, so expect some behaviour
> changes". Precisely how much newer, and precisely which behaviour changes,
> is not such a simple question to answer: it depends which package's
> behaviour you're interested in, and if you want to answer that question,
> the only way is to look at individual packages, so that you can tell
> whether they were last updated in January or whether they have been
> updated to July's version.

If you chroot into /tmp/b after you create /tmp/d, and you update it,
you will get content that matches /tmp/d, not /tmp/c (yes yes if you
touched /tmp/b in some ways there will be subtle differences, and
weird breakages might happen from time to time, but you know what I
mean). sid remains sid, it will never be trixie, it will never become
released with security support, then move to ELTS, and then go EOL. A
particular instance might have some out of date content, but that's
true of every OS tree in the universe, but it fundamentally doesn't
change its identification from the point of view of os-release. The
fact that some content might match the content of other releases
doesn't change anything in the specific context of os-release - again
it's fine to have a philosophical discussion on what actually
constitutes a pipe, but this is not the purpose of this ticket - in
fact, we have many many packages that never get rebuilt, and that are
bit-by-bit identical from oldoldstable to oldstable to stable to
testing to unstable. Does it mean that os-release in bullseye is wrong
to identify it as bullseye and should say 'sid' instead, because some
packages are identical and indistinguishable between the two?

This is trying to ascribe a meaning to os-release that it really
doesn't have, and nobody I know of uses it for. Because it doesn't
tell you "yes this is exactly up to date at the time you are reading
it". It tells you, "this is what this vendor tree was, at the time it
was last updated or created", and yes, this is useful and needed
information to convey. If you create an Archlinux or a SUSE Tumbleweed
vendor tree now, and another one next year, they will be massively
different. os-release will still, correctly, say the same thing.
Because it is not a statement about updated-ness, it's a statement
that captures the identity of a vendor tree at the point in time it
was touched. As mentioned already in a separate mail, we actually have
optional fields like BUILD_ID where timestamps can be added, if that
needs to be tracked. A VERSION_CODENAME doesn't mean content will
always be the same - it's not a reflection on every single bit of its
content. It's the identity of the tree that matters.
And again to bring up the same real world example from the other mail,
if you do debootstrap bookworm in August last year, and you do that
again in August 2026, the content will be wildly different in terms of
pack

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Fri, 02 Aug 2024 at 10:31:29 +0200, Marc Haber wrote:
> On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> > 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.
> 
> Not even automatically. /etc/os-release is a conffile, isnt it?

No, it's canonically a symlink to /usr/lib/os-release which is "owned"
by the packaging system (specifically base-files.deb, although Luca's
proposal in this thread involves moving it to another package). It's
technically possible to delete the symlink, replace it with a regular
file and edit the regular file, for example to add a VARIANT or IMAGE_ID
- although I'm not sure how that would interact with upgrades, and in
practice the situation where you'd be most likely to do that would be
an image-based environment where you throw away the image and bootstrap
a new one instead of upgrading.

smcv

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > It could be a dependency of something else, or it could be marked as
> > essential itself, given the content is a 5 lines text file and a symlink
> > it shouldn't be too hard to figure out an acceptable way to ensure it
> > ships everywhere. It doesn't have to be related to base-files at all, it
> > was just the first thing that came to mind.
>
> Given that it's included in base-files now and base-files is essential, I
> believe it has to continue to be provided by an essential package, unless
> we want to try to do the work of figuring out if os-release can be removed
> from essential (and I would not be eager to do that).
>
> Since it is part of the essential set, though, I'm not sure the dependency
> from base-files is actually needed (but also it may not really matter).  I
> think dependencies between essential packages are only really used during
> the bootstrapping phase, and presumably os-release is not needed by
> bootstrapping.
>
> Anyway, I haven't done any work in this area of Debian so I'll leave this
> for other people with more relevant expertise to comment on.

Yeah it really has to be part of the essential set, it's just expected
to be there in the minimalest of barest vendor trees. Priority:
essential is probably the easiest.

> [version numbers]
> > The really important part is adding different and separate codenames, so
> > that a testing image can be reliably and univocally distinguished from a
> > sid image, and VERSION_CODENAME is enough for that, the version number
> > is cherry on top.
>
> Like Santiago, I admit to not finding this use case compelling.  Most of
> the reasons why I might imagine someone would want to do this sound like
> misunderstandings of how Debian works, given that in many cases, excluding
> the apt configuration, today's unstable image is next week's testing image
> without changing a single byte on disk.  In other words, in the cases
> where this does make sense, I feel like this desire is usually a proxy for
> "what package pool will *new* packages for this image be drawn from," and
> using os-release to guess at that information seems at least a bit
> questionable.  If what someone cares about is apt configuration, it seems
> better to get that information from apt directly, not via a fallible proxy
> (and maybe we need a better way to do that).

That's yet another Debian-specific workaround. The point of this is,
again, answering the question "what is this vendor tree" _without_
distro specific kludges. That's the entire reason for os-release to
exist. If the answer at any point is "check os-release AND THEN run
this distro specific set of scripts or binaries", then the answer is
wrong, and the implementation of the spec is buggy. Again, one might
say "I am ok with this being buggy because we gain X Y and Z in
exchange", but buggy it is and buggy it will remain.
apt might not even be installed or configured in an otherwise correct
and minimal read-only OS tree. It's not just about your laptop or your
server, it's about building, running, stacking and identifying many
types of images - bare metal, virtual, container, chroot, you name it.
Please see examples in my other email to Helmut.

> However, it doesn't seem obviously *bad* to do this either, and I trust
> that you have reasons why you think this is important.
>
> > But this example seems a bit too tortured to me.
>
> Well, it's related to your example of the zoom package basing decisions on
> the version number.  If they had done that based on a version number of
> testing, there's a fairly high chance that whatever decisions they made
> would be wrong by the time the stable release happens, particularly if
> they do that early in a release cycle.
>
> That said, I would expect most third-party non-free packages like that to
> not care at all about anything in Debian until it reached stable, so the
> chances of them doing that may be low.

Uh, I did not provide an example regarding zoom? Where's that from?

> > And secondly, that same strawman
>
> straw man (noun)
>
> 1: a weak or imaginary opposition (such as an argument or adversary)
>set up only to be easily confuted
>
> This is the sort of thing I was talking about when I said insults.  I'm
> not sure if you're using this term with some non-standard definition
> (believable, since I was using this argument in the opposite way from how
> one would use a straw man), but the normal implication of calling my
> argument a straw man is that I was arguing in bad faith.  This comes
> across as weirdly aggressive and makes these discussions unnecessarily
> annoying.

I admit I don't really pick up the Oxford dictionary every time I have
to write an email, as there's not enough time in the world. I meant it
as something like "example constructed during an argument that you
cannot find in the real world".
And look, I live in Scotland. When I'll actually mean to insul

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Thu, 01 Aug 2024 at 20:00:40 -0700, Russ Allbery wrote:
> I just know that I've seen a lot of code that uses version
> numbers or code names this way, mostly in things like Puppet rules.  Most
> of the time people will probably get this right, but there are some
> obvious potential mistakes such as coding a condition that says 13 behaves
> the same as 12 (but the eventual release won't) or that 13 always behaves
> in some new way (but testing systems that weren't upgraded to the released
> version 13 don't and instead behave like 12).

I think the only right ways to handle version-dependent conditions
are either feature detection (looking for the feature of interest, e.g.
dpkg --assert-versioned-provides), or looking at the version number of the
(possibly backported) package of interest (e.g. dpkg-query -W systemd),
or if neither of those is feasible, something like this pattern:

if major_version <= 11:
do old things
else if major_version == 12:
do things suitable for bookworm
else:
assume testing/unstable/future and do new things

with more or fewer "else if" depending on the number of major versions
with divergent behaviour that you aim to support. All of those patterns
would work without a VERSION_ID in testing/unstable, or even without a
VERSION_CODENAME.

But, obviously, third-party software doesn't always get this right, and
will sometimes say things like "all Debian systems except testing/unstable
have 32-bit time_t on armhf" - which happens to be true *today*, but will
immediately become false when we release trixie.

> The most mistake-resistant approach would be to give
> testing some *other* code name that isn't trixie, and only give the code
> name of trixie at the time of release, but that's also weirdly different
> from how we use codenames in the archive structure

That also breaks some of the design principles of the
unstable -> testing -> stable flow, which are that testing should be
approximately equivalent to a previous state of unstable (one where
everything worked acceptably together), the next stable should be
functionally equivalent to a late-freeze version of testing, and as
little as possible should change as we cross release milestones, to
avoid perturbing packages' behaviour.

We don't 100% stick to those design principles, because getting all of
unstable into a state where it works acceptably together and is ready
to migrate is not actually feasible most of the time, so instead we
migrate a package or a group of packages at a time - but the design goal
is that there are no surprises when testing is updated, because every
behaviour change has already been seen before, in unstable. So I can
understand why Santiago is reluctant to have testing and unstable be
obviously, identifiably different.

I think the release team needs to be involved in the decision of how
testing and unstable should be labelled, because it's the release team
that is responsible for the flow of packages from unstable into testing
and the flag-day transition from "trixie is testing" to "trixie is stable",
and it's also the release team that would have to deal with the fallout
if packages changed their behaviour (possibly during hard freeze!) when
they saw /etc/os-release change from unstable to trixie.

In other distributions like Fedora and Ubuntu, the branch that is going
to become the next stable (Fedora rawhide, Ubuntu devel) is already
labelled as though it *was* the next stable. The Debian equivalent of
this would be to label testing as Debian 13, trixie, starting as soon
as the branch opens (I often call it something like "a Debian 13 alpha"
when I need to communicate its status to developers outside the Debian
bubble) and I think that would be a reasonable thing to do.

The unusual thing about Debian is that we have not one but two "future"
branches, unstable and testing, together with the unstable -> testing
migration, *and people actually use unstable*. In Fedora, I believe
new packages go directly to rawhide (the Debian equivalent would be not
having unstable, and uploading directly to testing), and the VERSION_ID
in rawhide is the major version that the *next* Fedora release will
have (so, yes, the Debian equivalent would be to have had VERSION_ID=13
starting from the beginning of trixie).

In Ubuntu, they do technically have an equivalent of unstable (they call
it "proposed"), but my understanding is that nobody outside the Ubuntu
infrastructure actually runs it on their computers - the ability to
install it on systems other than buildds isn't advertised. So if it's
mis-labelled, there's no actual practical impact, because it's very
close to their equivalent of testing, and nobody is running third-party
software on it anyway. In terms of how it's used, it's more like Debian's
buildd-unstable branch, used on buildds, QA/test infrastructure and
nowhere else.

The closest equivalent of what Fedora and Ubuntu do would be to label
both testing and unstable as tho

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> The second [objection from the base-files maintainer] is pushing forward a
> philosophical explanation according to which testing and unstable are
> not actually different images, but they are one and the same (two sides
> of the same coin is the expression used). While that might be true in a
> philosophical sense, this is a practical matter, and it concerns only
> the os-release specification and its implementation. In such context,
> testing and unstable are different and independent images, built from
> different and independent archives of packages. For example, at any
> point in time you can do:
> 
> deboostrap testing /tmp/a
> deboostrap unstable /tmp/b
> 
> and if your shell history is lost, you have no reliable, stable,
> distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.

But, let's continue your example: suppose you ran those commands back in
January. Now, 6 months later, run similar commands again:

debootstrap testing /tmp/c
debootstrap unstable /tmp/d

With your proposed labelling of testing and unstable as being fundamentally
different, you would have:

/tmp/a: testing from January, labelled as testing (or trixie or Debian 13)
/tmp/b: unstable from January, labelled as unstable
/tmp/c: testing from July, labelled as testing (or trixie or Debian 13)
/tmp/d: unstable from July, labelled as unstable

But, contrary to that, the differences between a and b will be relatively
small, and so will the differences between c and d; whereas the differences
between a and c will be large (even though they're both labelled as
testing) and so will the differences between b and d.

For example, a and b will have glibc 2.37, but c and d will have 2.39,
with whatever behaviour changes have happened in the last 6 months.
Similarly, neither a nor b has been through the t64 transition, but
both c and d have.

I think the most important fact about all of these chroots is
"it's strictly newer than Debian 12, so expect some behaviour
changes". Precisely how much newer, and precisely which behaviour changes,
is not such a simple question to answer: it depends which package's
behaviour you're interested in, and if you want to answer that question,
the only way is to look at individual packages, so that you can tell
whether they were last updated in January or whether they have been
updated to July's version.

smcv
(not a TC member)

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Thu, Aug 01, 2024 at 11:51:45PM +0200, Helmut Grohne wrote:
> Conversely, I am unsure how to distinguish testing and unstable myself.
> Say I operate an unstable system and eventually decide that my ride is
> too bumpy and I prefer running testing, I may edit my sources.list and
> after a month or so my system will have reasonably converged to testing.
> At what point would my /etc/os-release change?

Probably never since the os-release version in unstable would always
have to be higher than the one in testing to not confuse dak. But alas,
such an unstable-going-testing system will probably never be a "true"
testing system since it will continue to keep packages that were removed
from testing but not from unstable. Therefore, after the system has
"reasonably converged" to testing, the local admin (you) would have to
compare package lists anyway, and at this stage an apt --force-downgrade
os-release or its working equivalent would be in order.

> Russ raised the question of how to represent a testing system that pulls
> some packages from unstable.

That would stil be a testing system in my opinion. One of the core
(mis)features of testing is that you don't get as speedy security
support as you get in stable or unstable in most cases. This should be
automatically distinguishable.

Using apt-pinning it is possible to have a system misrepresent itself in
most arbitrary ways, so if you want to be really sure you'd need to look
at the versioned set of installed packages, but that's the pain you
asked for yourself.

> > This has resulted in numerous downstream users, tools, scripts and code
> > having to employ fragile Debian-specific hacks, such as trying to grep
> > /etc/apt/sources.list in an attempt to catch "unstable/sid" or
> > "testing" keywords, which of course is can break spectacularly, for
> > example if apt is not configure in an image (which is normal in a read-
> > only image-based system), or if both unstable and testing repositories
> > are present, with unstable pinned via apt-preferences to 1. Other
> > distributions do not have this issue, it is only a problem that Debian
> > forces its users to deal with, causing grief and pain.
> 
> Given the issues you experienced, would you be kind enough to reference
> some of them here?

For example, having ansible playbooks that support testing becoming
stable without breaking the systems or having to do in-sync changes to
the inventory is unnecessarliy hard and error-prone.

> We have a disagreement about whether the information you intend to
> convey actually exists beyond the point in time where you deboostrap. If
> I debootstrap unstable and look at it a week later, it more closely
> represents testing than unstable.

Not quite, it would have packages that are not in testing. And if
upgraded, it would upgrade von unstable.

> Conversely, we might consider that the os-release specification that is
> meant to cover the various aspects of Linux distributions is a poor fit
> for Debian and that its expressiveness is too limited to accurately
> represent the migration-based approach that Debian uses to assemble its
> releases. We might consider this a bug in the os-release specification
> and we may even disagree with the os-release specification upstream (aka
> you) about that. It all depends on how you look at it.

I would expect from Debian to work constructively with the os-release
specification upstream to adapt the specification that it might be a
better fit for Debian some time in the future. If we divert from the
specs here, distribution independent tools (like ansible, python, puppet
etc) are unlikely to go along and special case Debian.

> As far as I read the specification, no field is mandatory. This gives
> rise to another solution to come into compliance with the letter of the
> specification: Drop the VERSION_CODENAME from /etc/os-release just as
> the VERSION is already dropped. As far as I can see, all other fields
> have compliant values.

That would make the file even less useful than it it today. A classical
lose-lose solution. Please don't do that.

> I'd like to better understand the problems caused by the imprecise
> implementation of the os-release specification as that aspect is still
> quite sketchy in your request.

Configuration Management, CMDBs, both in heterogenous fleets, using
standard software that isn't willing to specialcase Debian.

Greetings
Marc

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Thu, Aug 01, 2024 at 12:06:21PM -0700, Russ Allbery wrote:
> The second thing that I'm not fond of is giving testing the version number
> 13 when we plan on using 13 as the version number for the trixie release.
> I fear that if we do that, someone (probably a third-party package
> provider) will add some workaround or behavior change for a package based
> on that version number for a problem that only ever existed in testing and
> that was not in the actual 13 release.  I would instead expect testing to
> use some version number that is between stable and the version number that
> will be assigned to the next release, to reflect that it is likely to
> change substantially before Debian makes an actual release 13.

And we cannot even use 13~, since we might release trixie as 12.9 or
something. So that decision would have to be taken early by the release
team, and it is almost impossible to revert.

Does the proposal include lanugage about what to put in the Version:
field in debian/control of the proposed package? Would it be pulled in
by a versioned dependency (in base-files)?

> (If I were designing this from scratch, I'd give serious thought to using
> even version numbers for releases and odd version numbers for testing,
> similar to how Perl releases are versioned for very similar reasons.  But
> that's probably too big of a change for the level of benefit.)

Using yy.mm as release version number is one of the things that Ubuntu
does right. I'd suggest going that path should we decide to touch
version numbering.

> Presumably the RELEASE_TYPE setting of pre-release is supposed to help
> with that, but (a) that variable doesn't seem to be documented in
> os-release(5); (b) the sorts of packagers that I'm worried about are quite
> likely to not make subtle distinctions like that, so the version is still
> there as a potential foot-gun for people who aren't paying close
> attention; and (c) I would argue that calling testing a "pre-release" is
> not very accurate, since that applies that the contents are very similar
> to the eventual release and are in a relatively late stage of testing.

Local variables in os_release are unlikely to be picked up by
distribution independent tools like ansible and are thus of very limited
usefulness.

> There's a lot of merit to Santiago's decision to not give unstable a
> version number that I think still applies to testing even when it's
> considered separately.

It would be very nice to not have to do a two-stage distribution
comparision in ansible playbooks or such, and to be able to do a numeric
comparision. Personally, I currently reference my debian versions on
codenames, which puts a lot of distribution specific knowledge about
codenames into my playbooks. I am not very fond of that, but it is just
a single stage, and it allows me to install new machines on trixie NOW
and have them automatically migrate over when trixie becomes stable. I
think that I had to define a local variable to accomplish this in my
playbooks, but that's a few years in the past. It may be possible easier
today.

> > 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.
> 
> That seems like a better approach than the one proposed in the message
> above, although I think it requires some manual intervention by the
> release team.  This doesn't seem like a serious problem given that uploads
> are presumably quite infrequent and the package is trivial.

For this method to work the package MUST be trivial, if not impossible
to get wrong.

Greetings
Marc

Bug#1077764: Ruling request on os-release specification implementation

[Marc Haber]

On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> 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.

This also means that os-release NEEDS to be managed in a package that is
easy to get bug free: Either automatically generated or so simple that
it's impossible to get wrong. The "testing" version of the package that
will be promoted to stable on release day will never be in unstable,
thus bugs in that package will be fatal immediately.

This in my opinion rules out the option of keeping this inside
base-files, which is a complex package that I really want to see managed
through the normal unstable-testing-stable mirgration process.

> 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).

Hence, on such systems os-release is ALWAYS wrong in one or the other
way, hence the local admin is on her own here. I don't see that as a
problem.

> 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.

Not even automatically. /etc/os-release is a conffile, isnt it?

Greetings
Marc

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  writes:

> It could be a dependency of something else, or it could be marked as
> essential itself, given the content is a 5 lines text file and a symlink
> it shouldn't be too hard to figure out an acceptable way to ensure it
> ships everywhere. It doesn't have to be related to base-files at all, it
> was just the first thing that came to mind.

Given that it's included in base-files now and base-files is essential, I
believe it has to continue to be provided by an essential package, unless
we want to try to do the work of figuring out if os-release can be removed
from essential (and I would not be eager to do that).

Since it is part of the essential set, though, I'm not sure the dependency
from base-files is actually needed (but also it may not really matter).  I
think dependencies between essential packages are only really used during
the bootstrapping phase, and presumably os-release is not needed by
bootstrapping.

Anyway, I haven't done any work in this area of Debian so I'll leave this
for other people with more relevant expertise to comment on.

[version numbers]
> The really important part is adding different and separate codenames, so
> that a testing image can be reliably and univocally distinguished from a
> sid image, and VERSION_CODENAME is enough for that, the version number
> is cherry on top.

Like Santiago, I admit to not finding this use case compelling.  Most of
the reasons why I might imagine someone would want to do this sound like
misunderstandings of how Debian works, given that in many cases, excluding
the apt configuration, today's unstable image is next week's testing image
without changing a single byte on disk.  In other words, in the cases
where this does make sense, I feel like this desire is usually a proxy for
"what package pool will *new* packages for this image be drawn from," and
using os-release to guess at that information seems at least a bit
questionable.  If what someone cares about is apt configuration, it seems
better to get that information from apt directly, not via a fallible proxy
(and maybe we need a better way to do that).

However, it doesn't seem obviously *bad* to do this either, and I trust
that you have reasons why you think this is important.

> But this example seems a bit too tortured to me.

Well, it's related to your example of the zoom package basing decisions on
the version number.  If they had done that based on a version number of
testing, there's a fairly high chance that whatever decisions they made
would be wrong by the time the stable release happens, particularly if
they do that early in a release cycle.

That said, I would expect most third-party non-free packages like that to
not care at all about anything in Debian until it reached stable, so the
chances of them doing that may be low.

> And secondly, that same strawman

straw man (noun)

1: a weak or imaginary opposition (such as an argument or adversary)
   set up only to be easily confuted

This is the sort of thing I was talking about when I said insults.  I'm
not sure if you're using this term with some non-standard definition
(believable, since I was using this argument in the opposite way from how
one would use a straw man), but the normal implication of calling my
argument a straw man is that I was arguing in bad faith.  This comes
across as weirdly aggressive and makes these discussions unnecessarily
annoying.

> can be applied to stable, as we do point releases and security uploads.

I am surprised that point releases don't change VERSION_ID, and now I'm
curious why that's the case.  I was assuming, having not previously looked
at it, that VERSION_ID would match /etc/debian_release, but I see that it
doesn't and has only the major version.

Regardless, security uploads do potentially create this problem, but we
also try pretty hard to not change major functionality in security uploads
in ways that may prompt someone to want to change behavior based on that
version.  There is a window of possibility there, I think it's
sufficiently narrow to not worry that much about.  It's at least a much
narrower problem than version numbers in testing.

I'm not sure how important this is, and all the options have obvious
problems.  I just know that I've seen a lot of code that uses version
numbers or code names this way, mostly in things like Puppet rules.  Most
of the time people will probably get this right, but there are some
obvious potential mistakes such as coding a condition that says 13 behaves
the same as 12 (but the eventual release won't) or that 13 always behaves
in some new way (but testing systems that weren't upgraded to the released
version 13 don't and instead behave like 12).

This problem also applies to codenames, which I've seen used in Puppet
rules as well (more often than version numbers, in fact), so we already
have this problem since, as you pointed out when opening this bug, the
current base-files os-release file declares unstable and testing

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 22:52, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
> > This is an escalation requesting a ruling on the matter of several
> > base-files bugs around its buggy implementation of the os-release
> > specification, the most recent example being #1021663 and other
> > instances that I could find with a cursory look being #1008735 and
> > #675731.
>
> I observe that Santiago has replied to each of them with patience and
> that he has presented relatable reasons for his choices.
>
> As you detail later, it seems that the corner stone of your complaint is
> that an unstable installation should have VERSION_CODENAME=sid rather
> than VERSION_CODENAME=trixie. Do you agree with this characterization?

Yes, _and_ testing should have VERSION_CODENAME=trixie at the same
time, to be precise. I.e., the very core of the conflict is about
whether being able to tell the difference between testing and unstable
should be possible following the distro-agnostic os-release
specification.

> > The TL;DR is a request to override the base-files maintainer, and
> > enable moving os-release into a new, independent and separate source
> > package, so that these bugs may finally be fixed, and Debian's os-
> > release may finally be made compliant with the specification.
>
> On a process level, the CTTE can only decide among available options. In
> this context available roughly equates the existence of a patch (or
> source package). Reading multiple bugs, I found disagreement on this
> approach, but no code that could be characterized as a reviewable
> solution.

Well you know this better than me of course, but isn't this also
something you can do? Decide between:

1) The os-release specification must be adhered to, and it must be
possible to tell the difference between testing vs unstable, and each
must be correctly identified by the respective metadata

or

2) Testing and unstable can continue to remain indistinguishable, and
both be erroneously identified as trixie

Again you'll know better than me, but it seems to me rulings were made
in the past that were along similar lines (eg: usrmerge) - there
wasn't reviewable code there, no?

> Another plausible way to interpret your mail is that you really ask the
> CTTE to override the base-files maintainer in claiming ownership of
> /etc/os-release in the base-files package request releasing the file to
> another package. Given that said file has become part of the essential
> interface, releasing it is subtle and warrants a more detailed look at
> how the take-over is supposed to happen. To me that process is too
> sketchy to consider at this time.
>
> > Numerous attempts were independently made by many different people to
> > try and convince the base-files maintainer to fix this issue, the
> > oldest one linked above being 12 years ago, and they have all been
> > rejected, as recently as today. The only course of action left is
> > therefore asking for a CTTE intervention in the matter, as all attempts
> > at mediation and negotiation over the years have failed.
>
> Evidently, there are multiple conflicting requirements that various
> parties would like to see implemented. The base-files maintainer has
> made a compromise and argued in favour of his position. Said compromise
> encompasses an interpretation of the os-release specification that does
> not follow it to the letter.

Sorry but I do not think that is an accurate representation. First of
all, the implementation of the spec is bugged, period - it's not about
being pedantic about it, it's about being completely incompatible: sid
is identified as trixie, and that is just plain wrong, and there's no
room for interpretation, no matter how one might try to bend it. You
might say that you don't _care_ that the implementation is buggy, you
might even say that it is worth, nay _good_ it to leave it buggy - but
buggy it is, if I create a sid image, it will never in a million years
be trixie, and yet it says it's trixie.

Secondly, I am not even sure what these conflicting requirements
actually are? Could you please spell them out? If trixie was
identified as trixie, and sid was identified as unstable, what
compromise would be, er, compromised, precisely? Because the only
practical objections I could find were based on the idea that
implementations would be ugly or hard to maintain or so - as already
mentioned, I am happy to relieve anybody else and take that hard and
ugly maintenance burden for myself. What other actual problem would
suddenly appear? What feature or advantage do we leave behind? How are
things made worse for our users?

> > The os-release specification, of which I am an upstream author and
> > maintainer, defines a distro-agnostic text-based metadata format to
> > allow identifying Linux distributions images, root directories, trees
> > and whatnot, without requiring distro-specific quirks, executables,
> > binaries, scripts or workarounds. 

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
> This is an escalation requesting a ruling on the matter of several
> base-files bugs around its buggy implementation of the os-release
> specification, the most recent example being #1021663 and other
> instances that I could find with a cursory look being #1008735 and
> #675731.

I observe that Santiago has replied to each of them with patience and
that he has presented relatable reasons for his choices.

As you detail later, it seems that the corner stone of your complaint is
that an unstable installation should have VERSION_CODENAME=sid rather
than VERSION_CODENAME=trixie. Do you agree with this characterization?

> The TL;DR is a request to override the base-files maintainer, and
> enable moving os-release into a new, independent and separate source
> package, so that these bugs may finally be fixed, and Debian's os-
> release may finally be made compliant with the specification.

On a process level, the CTTE can only decide among available options. In
this context available roughly equates the existence of a patch (or
source package). Reading multiple bugs, I found disagreement on this
approach, but no code that could be characterized as a reviewable
solution.

Another plausible way to interpret your mail is that you really ask the
CTTE to override the base-files maintainer in claiming ownership of
/etc/os-release in the base-files package request releasing the file to
another package. Given that said file has become part of the essential
interface, releasing it is subtle and warrants a more detailed look at
how the take-over is supposed to happen. To me that process is too
sketchy to consider at this time.

> Numerous attempts were independently made by many different people to
> try and convince the base-files maintainer to fix this issue, the 
> oldest one linked above being 12 years ago, and they have all been
> rejected, as recently as today. The only course of action left is
> therefore asking for a CTTE intervention in the matter, as all attempts
> at mediation and negotiation over the years have failed.

Evidently, there are multiple conflicting requirements that various
parties would like to see implemented. The base-files maintainer has
made a compromise and argued in favour of his position. Said compromise
encompasses an interpretation of the os-release specification that does
not follow it to the letter.

> The os-release specification, of which I am an upstream author and
> maintainer, defines a distro-agnostic text-based metadata format to
> allow identifying Linux distributions images, root directories, trees
> and whatnot, without requiring distro-specific quirks, executables,
> binaries, scripts or workarounds. It has been adopted pretty much
> universally on Linux, including in Debian since 2012. It supersedes
> deprecated tools and specifications such as lsb_release and distro-
> specific files such as debian_release.
> 
> Spec:
> 
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html
> 
> With my upstream spec maintainer hat on, I am asserting that the base-
> files implementation of the os-release specification is buggy. This has
> always been the case, since the very beginning, as it can be seen in
> the oldest of the bugs linked above. The crux of the issue is that the
> way base-files implements the specification does not allow to
> distinguish testing vs unstable images, and worse than that, it
> recently started providing wrong and misleading information,
> incorrectly identifying sid as trixie (via VERSION_CODENAME=trixie).

Please allow me to raise the question of what is the benefit of
differentiating sid and trixie in /etc/os-release. I am inclined to
agree that VERSION_CODENAME would be technically wrong in unstable, but
we have a history of sometimes bending rules. For instance libc6 being
Multi-Arch: same technically is a lie as multiple architectures share
the same dynamic loader path. A strict interpretation would require us
to remove Multi-Arch: same, but that would make much of Multi-Arch
useless. Likewise, linux-libc-dev is currently declared Multi-Arch:
foreign, which also is a technical lie. We also tolerate violations of
Debian policy in exceptional circumstances. Given the arguments
presented by the base-files maintainer, I kindly request more specific
details on what use case is broken by being unable to differentiate
testing and unstable.

Conversely, I am unsure how to distinguish testing and unstable myself.
Say I operate an unstable system and eventually decide that my ride is
too bumpy and I prefer running testing, I may edit my sources.list and
after a month or so my system will have reasonably converged to testing.
At what point would my /etc/os-release change?

Russ raised the question of how to represent a testing system that pulls
some packages from unstable.

> This has resulted in numerous downstream users, tools, scripts and code
> having to employ fragi

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 20:06, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > 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
>
> Ah, thank you.  I think that answers my questions.
>
> To summarize briefly to ensure that I understand, your proposal is to
> separate only this content into a second package, make base-files depend
> on it, and then maintain different versions of that package in unstable
> and testing.
>
> There are two technical aspects of this proposal that worry me.
>
> The first is adding a dependency to base-files.  I know people have put a
> whole lot of work into pure dependency-based bootstrapping for Debian, but
> historically base-files has been very special and posed lots of
> interesting complications that are separately handled in lots of different
> tools.

It could be a dependency of something else, or it could be marked as
essential itself, given the content is a 5 lines text file and a
symlink it shouldn't be too hard to figure out an acceptable way to
ensure it ships everywhere. It doesn't have to be related to
base-files at all, it was just the first thing that came to mind.

> I do agree with Santiago's desire to maintain base-files as a "normal"
> Debian package that gets tested in unstable and propagates to testing, so
> if we go down this route, splitting out this data does seem better to me
> than maintaining multiple lines of development for base-files itself.
>
> The second thing that I'm not fond of is giving testing the version number
> 13 when we plan on using 13 as the version number for the trixie release.
> I fear that if we do that, someone (probably a third-party package
> provider) will add some workaround or behavior change for a package based
> on that version number for a problem that only ever existed in testing and
> that was not in the actual 13 release.  I would instead expect testing to
> use some version number that is between stable and the version number that
> will be assigned to the next release, to reflect that it is likely to
> change substantially before Debian makes an actual release 13.

The version number is the least important part of the changes - so for
example, it could still be omitted until the actual release like it is
now. The really important part is adding different and separate
codenames, so that a testing image can be reliably and univocally
distinguished from a sid image, and VERSION_CODENAME is enough for
that, the version number is cherry on top. I still think that trixie
is 13 and 13 is trixie, so there's no point in delaying, as that piece
of metadata is not going to change, and I think it would be better if
"debootstrap trixie" always gave the same identification metadata
(barring the release type as per below perhaps) but it's not a crucial
matter and it's fine either way, in the end.
But this example seems a bit too tortured to me. First, if you add a
workaround like that, you would normally do it based on the package
version you are working around, or at least that's how I usually do it
and see it done. And secondly, that same strawman can be applied to
stable, as we do point releases and security uploads. One could see a
bug in bookworm and decide to check for VERSION_ID=12 to work around
it, even if that bug is later solved in a point release or security
update. It is still correct to mark stable as VERSION=12 (without the
point release).

> (If I were designing this from scratch, I'd give serious thought to using
> even version numbers for releases and odd version numbers for testing,
> similar to how Perl releases are versioned for very similar reasons.  But
> that's probably too big of a change for the level of benefit.)
>
> Presumably the RELEASE_TYPE setting of pre-release is supposed to help
> with that, but (a) that variable doesn't seem to be documented in
> os-release(5);

What do you mean?!! It's right there!
https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=

...ok, ok, it's there now because I just merged it and regenerated the docs :-P

> (b) the sorts of packagers that I'm worried about are quite
> likely to not make subtle distinctions like that, so the version is still
> there as a potential foot-gun for people who aren't paying close
> attention; and (c) I would argue that calling testing a "pre-release" is
> not very accurate, since that applies that the contents are very similar
> to the eventual release and are in a relatively late stage of testing.

As above, if someone wants to abuse the version to pin things, it can
already happen in all stable point releases too. In fact with kernel
upstream LTS releases being part of those, the amount of changes in a
Debian stable point release is actually quite large, and it does
happen often that those kernel LTS releases either break egre

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  writes:

> 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

Ah, thank you.  I think that answers my questions.

To summarize briefly to ensure that I understand, your proposal is to
separate only this content into a second package, make base-files depend
on it, and then maintain different versions of that package in unstable
and testing.

There are two technical aspects of this proposal that worry me.

The first is adding a dependency to base-files.  I know people have put a
whole lot of work into pure dependency-based bootstrapping for Debian, but
historically base-files has been very special and posed lots of
interesting complications that are separately handled in lots of different
tools.

I do agree with Santiago's desire to maintain base-files as a "normal"
Debian package that gets tested in unstable and propagates to testing, so
if we go down this route, splitting out this data does seem better to me
than maintaining multiple lines of development for base-files itself.

The second thing that I'm not fond of is giving testing the version number
13 when we plan on using 13 as the version number for the trixie release.
I fear that if we do that, someone (probably a third-party package
provider) will add some workaround or behavior change for a package based
on that version number for a problem that only ever existed in testing and
that was not in the actual 13 release.  I would instead expect testing to
use some version number that is between stable and the version number that
will be assigned to the next release, to reflect that it is likely to
change substantially before Debian makes an actual release 13.

(If I were designing this from scratch, I'd give serious thought to using
even version numbers for releases and odd version numbers for testing,
similar to how Perl releases are versioned for very similar reasons.  But
that's probably too big of a change for the level of benefit.)

Presumably the RELEASE_TYPE setting of pre-release is supposed to help
with that, but (a) that variable doesn't seem to be documented in
os-release(5); (b) the sorts of packagers that I'm worried about are quite
likely to not make subtle distinctions like that, so the version is still
there as a potential foot-gun for people who aren't paying close
attention; and (c) I would argue that calling testing a "pre-release" is
not very accurate, since that applies that the contents are very similar
to the eventual release and are in a relatively late stage of testing.

There's a lot of merit to Santiago's decision to not give unstable a
version number that I think still applies to testing even when it's
considered separately.  However, you do have a good point that this makes
life difficult for third-party packages that want to enforce a minimum
version number because there's no way to then tell that, although this is
a testing release with no real version number, it does come after version
12.  (Obviously this is not a great way to handle dependencies on a Debian
release, and we probably wouldn't allow it in a regular Debian package,
but third-party packages often do things like this.)  I'm not sure which
side of that trade-off I'd fall on, although I do think not having a
version number is more semantically correct given the current language
documented in os-release(5).  If RELEASE_TYPE were added to the spec with
an additional type of "development-snapshot" or something else more
accurate than "pre-release", that might change my mind, although my point
(b) above still applies.

> 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.

That seems like a better approach than the one proposed in the message
above, although I think it requires some manual intervention by the
release team.  This doesn't seem like a serious problem given that uploads
are presumably quite infrequent and the package is trivial.

> 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.

Thanks, that answers the question that I was asking.  You're keeping the
same semantics as we currently have with base-files, and you're proposing
maintaining two different lines of development for the package containing
this file, one for unstable and one for testing.

> There are for sure a lot of criticisms of the bugs in base-files, but
> there are no insults.

Debian would be a far more enjoyable project to work on if you would
recalibrate your understanding of what is an insult.  Right now, it
requires substantial effort to read any thread that

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 18:33, Russ Allbery  wrote:
>
> Luca Boccassi  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.

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  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'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.

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.

-- 
Russ Allbery (r...@debian.org)  

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Thu, 1 Aug 2024 at 17:32, Christoph Berg  wrote:
>
> Re: Luca Boccassi
> > The TL;DR is a request to override the base-files maintainer, and
> > enable moving os-release into a new, independent and separate source
> > package, so that these bugs may finally be fixed, and Debian's os-
> > release may finally be made compliant with the specification.
>
> If we are fixing that, we should also fix /etc/debian_version in the
> same way. I've always been wondering why we don't put better content
> into these files.
>
> (Though I'm not sure the ruling should include the "move to new source
> package" part. It could also be fixed inside base-files.)

I left that out intentionally, as that is by definition a
Debian-specific file and the main goal here is fixing the
distro-agnostic metadata issues, and also changing that might affect
backward compatibility of existing consumers (not an issue in
os-release, as the relevant metadata is either absent or the wrong one
is very new). However, I personally do not have a strong opinion one
way or the other, and I am happy to do extra work if required.

Bug#1077764: Ruling request on os-release specification implementation

[Christoph Berg]

Re: Luca Boccassi
> The TL;DR is a request to override the base-files maintainer, and
> enable moving os-release into a new, independent and separate source
> package, so that these bugs may finally be fixed, and Debian's os-
> release may finally be made compliant with the specification.

If we are fixing that, we should also fix /etc/debian_version in the
same way. I've always been wondering why we don't put better content
into these files.

(Though I'm not sure the ruling should include the "move to new source
package" part. It could also be fixed inside base-files.)

Christoph

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

Package: tech-ctte

Dear CTTE,

This is an escalation requesting a ruling on the matter of several
base-files bugs around its buggy implementation of the os-release
specification, the most recent example being #1021663 and other
instances that I could find with a cursory look being #1008735 and
#675731.

The TL;DR is a request to override the base-files maintainer, and
enable moving os-release into a new, independent and separate source
package, so that these bugs may finally be fixed, and Debian's os-
release may finally be made compliant with the specification.

Numerous attempts were independently made by many different people to
try and convince the base-files maintainer to fix this issue, the 
oldest one linked above being 12 years ago, and they have all been
rejected, as recently as today. The only course of action left is
therefore asking for a CTTE intervention in the matter, as all attempts
at mediation and negotiation over the years have failed.

The os-release specification, of which I am an upstream author and
maintainer, defines a distro-agnostic text-based metadata format to
allow identifying Linux distributions images, root directories, trees
and whatnot, without requiring distro-specific quirks, executables,
binaries, scripts or workarounds. It has been adopted pretty much
universally on Linux, including in Debian since 2012. It supersedes
deprecated tools and specifications such as lsb_release and distro-
specific files such as debian_release.

Spec:

https://www.freedesktop.org/software/systemd/man/devel/os-release.html

With my upstream spec maintainer hat on, I am asserting that the base-
files implementation of the os-release specification is buggy. This has
always been the case, since the very beginning, as it can be seen in
the oldest of the bugs linked above. The crux of the issue is that the
way base-files implements the specification does not allow to
distinguish testing vs unstable images, and worse than that, it
recently started providing wrong and misleading information,
incorrectly identifying sid as trixie (via VERSION_CODENAME=trixie).

This has resulted in numerous downstream users, tools, scripts and code
having to employ fragile Debian-specific hacks, such as trying to grep
/etc/apt/sources.list in an attempt to catch "unstable/sid" or
"testing" keywords, which of course is can break spectacularly, for
example if apt is not configure in an image (which is normal in a read-
only image-based system), or if both unstable and testing repositories
are present, with unstable pinned via apt-preferences to 1. Other
distributions do not have this issue, it is only a problem that Debian
forces its users to deal with, causing grief and pain.

The base-files maintainer provides broadly two categories of
justifications for refusing to fix these issues. The first one is
dismissing any proposed solution as "ugly", without really
substantiating what it means - that is for example the case for
multiple proposals in #1021663. The second one is pushing forward a
philosophical explanation according to which testing and unstable are
not actually different images, but they are one and the same (two sides
of the same coin is the expression used). While that might be true in a
philosophical sense, this is a practical matter, and it concerns only
the os-release specification and its implementation. In such context,
testing and unstable are different and independent images, built from
different and independent archives of packages. For example, at any
point in time you can do:

deboostrap testing /tmp/a
deboostrap unstable /tmp/b

and if your shell history is lost, you have no reliable, stable,
distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
These, created at the same time, contain different packages and refer
to different archives, so while from a philosophical point of view one
might make one argument or the other, from the very specific, concrete
and real issue of implementing the os-release specification, they are
different releases and it must be possible to identify them as such,
and wrong information should not be conveyed to users.

There is also another common misunderstanding regarding what
constitutes a rolling release, sometimes used to justify avoiding to
fix these bugs. Again here such a concept from a philosophical point of
view might be bent into meaning many different things, but from the
point of view of the os-release specification, a rolling release is a
release that will never have a +1 or a -1 version. From the os-release
point of view, the fact that a distribution is updated often and gets a
lot of new packages, that might break ABI/API, or that is not security
supported, does not mean it is a rolling distribution. So unstable/sid
is a rolling distribution, because there will never be a new version,
it will always be sid. Trixie however is _not_ a rolling distribution,
because there is a trixie-1 (bookworm) and there will be a trixie+1
(forky). The fact t