Bug#1077764: Ruling request on os-release specification implementation

Timo Röhling <[email protected]> Mon, 5 Aug 2024 02:07:54 +0200
Newsgroups	gmane.linux.debian.devel.ctte
Organization	The Debian Project
Message-ID	<hjmv7onrzfsrezvfes2chmxeyo2jfbnv2aquinyjp66tqkg7v7__21368.6432269$1722816566$gmane$org@sesogp5pbhkj>
Hi,

* Luca Boccassi <[email protected]> [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 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.

>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.

>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?


Cheers
Timo

PS. I'm emailing out of vacation, so it might take me a few days to 
reply again.


-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯
signature.asc (application/pgp-signature, 833 B)