Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst <wouter@debian.org> wrote:
>
> On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst <wouter@debian.org> wrote:
> > >
> > > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne <helmut@subdivi.de> 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.
Reply to: