On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst <wou...@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 <hel...@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?
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 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.
Thanks,
[1] for clarity: I am not a member of the ctte, but I do have an opinion
here :)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
