Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 16:55, Wouter Verhelst <wouter@debian.org> wrote:
>
> On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst <wouter@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.
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 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.
Sure? None of that applies to image builders though, to name one of
the already cited examples of use cases.
> 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.
It's not an implementation detail: people do install and run sid and
testing as separate releases on working machines. This is a thing that
happens, as all our other tools, such as image builders, explicitly
allow that to happen. Are you arguing for debootstrap to stop allowing
to create unstable or testing images?
> 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*.
I have. It's ok if you don't like the answers, of course.
> 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.
It has: by implementing it. You'd be right if it wasn't present at
all, but it is. If you are suggesting base-files should just drop it
entirely, I'm all for it, although I would guess not for the same
reasons ;-)
Reply to: