On Mon, 5 Aug 2024 at 01:07, Timo Röhling <roehl...@debian.org> wrote: > > Hi, > > * Luca Boccassi <bl...@debian.org> [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.
