On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst <wou...@debian.org> 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 mixture, thanks.
