On Thu, 1 Aug 2024 at 14:29, Santiago Vila <sanv...@debian.org> wrote: > El 21/7/24 a las 11:36, Luca Boccassi escribió: > > There have been many bugs over the years, > > Well, my feeling is quite the opposite: I think there really > have not been so many bugs over the years.
The 3 CC'ed ones are the first ones I could find with a cursory look. The sheer amount of Debian-specific ugly hacks that are around because of this bug in base-files speaks volumes. > There is a paragraph in /usr/share/doc/base-files/FAQ saying > testing and unstable are sides of the same coin. Most people > read it and realize that differentiating between testing > and unstable is not such an important issue. In some cases > (read below) it may be even counter-productive and harmful. That FAQ is wrong, at the very least from the point of view of the os-release specification. Once again, you can do: debootstrap unstable a/ debootstrap testing b/ and then you have two different and independent images, running two different and independent sets of packages, from two different and independent archives, and no sensible way to distinguish them. It doesn't matter what you write down in your own FAQ, the specification is what matters. If you want to write a competing specification, with different semantics and contents, and convince other distros to adopt it instead of os-release, feel free to do so. But what base-files ships is not a spec-compliant os-release metadata file, and that's a bug in base-files. > Moreover, for some time, we had a smart "lsb_release" command > which actually looked at the sources.list file (the recommended > approach). That is not the recommended approach, that's a Debian-specific horrendous and fragile hack (hint: you can have _both_ unstable and testing lines in sources.list, with unstable apt-pinned at 1 or so, and then your recommendation falls apart). LSB is dead, and good riddance. We want to reduce these pointless and painful debianism, not make them proliferate. We should promote Debian based on what it's good at, not based on how much of a pain it is to use. > > and this issue keep biting. > > Just fell into it yet again. > > Well, that's vague and imprecise. When reporting bugs, one usually > tells what one did, what one expected, and what one got. > > I guess you simply expected VERSION_CODENAME to be "sid" on a system > running sid, but there are reasons why that's not reasonable or useful > and the FAQ attempts at explaining that. No, I expected to be able to tell if an image I am managing is trixie or sid, and it is impossible to do so reliably. It is a problem that exists only in Debian. > > os-release is the Linux > > standard for identifying images, and we need to make it useful for our > > users for testing and unstable too, not just for stable. > > This is unaccurate in several ways. You say that it's not useful for > testing, but that's not true. Also, you say that we need to make it useful > for unstable. Well, unstable is not a supported distribution, so that > would be at least subject to debate. As an upstream author and maintainer of the os-release specification, I can tell you with absolute certainty that it is in fact accurate. The way base-files generates os-release currently in Debian is bugged, and as per multiple bug reports has always been bugged. The wrong metadata is conveyed to users. This is not a matter of opinions, the spec is very clear. > > Currently in unstable/testing os-release contains: > > > > PRETTY_NAME="Debian GNU/Linux trixie/sid" > > VERSION_CODENAME=trixie > > > > And debian_version contains: > > > > trixie/sid > > > > This is confusing and breaks all the software out there that needs to > > distinguish between releases. > > Well, one might wonder what kind of software needs to differentiate > between testing and unstable. It may be the case that such software > is already broken to begin with. Any software that deals with images, root directories, and whatnot. And the only broken software here is base-files. > If you find the above confusing, there is a very simple explanation: > some fields are to be read by humans, and others are to be read by scripts > and the like. The file debian_version historically reads as trixie/sid > because its contents end up being shown to the end user on login screens, > while the more recent VERSION_CODENAME has the value "trixie", as it's > to be read by scripts which are meant to work in a system running trixie. And it's broken: an unstable image will be identified as "trixie", which is not unstable, it's something different. > [ At this point, I'll omit your split-os-release proposal from this quote, > it was already proposed by Gioele Barabucci and it was already rejected. > The funny thing is that you claim that looking at sources.list is ugly > and to solve your problem you make a proposal which is ten times uglier ]. Refusing to fix obvious bugs found by multiple users resulting in horrendous Debian-specific workarounds that no other distro subjects their users to, and the best justification you can find is that it's "ugly to do uploads"? > No, I don't think putting os-release in a different package is a good idea, > but I can agree that this needs to be better documented in the FAQ. > More explanations follow. > > The unstable distribution is surely a lot of different things for a lot of > different people, but among all those things, it's a staging area for the > testing distribution, which we also use "live" to help catch bugs before > they reach testing. > > If we implemented your os-release proposal and somebody uploads a package for > unstable which relies on VERSION_CODENAME having the values "bullseye", > "bookworm" or "trixie", the package will not work properly in unstable, > because VERSION_CODENAME would have a value which is none of those, > and users of unstable will think there is a bug in such package. This is a made-up strawman. There is no such package that I am aware of. Please provide actual evidence, if any. I have never seen anything like that, ever. > That's definitely not what we want. We want packages uploaded for unstable > to behave the same (or as close as possible) before and after they > propagate to testing, and for that purpose the value which makes most > sense for VERSION_CODENAME in both testing and unstable is the one it has > right now (trixie, or the testing of the time). > > In fact, if your package or script works currently ok in trixie but needs to > be different in unstable to work properly, your package will break sooner or > later, because packages from unstable propagate to testing all the time. Once again, this is not about a package or script. This is about identifying images. > For that reason, in general, it is a bad idea to target anything "for > unstable". > > And for that reason, that's something that we might better not encourage. > > Your insistence in having a different os-release for testing and unstable > is like complaining that the code generated by a cross-compiler may > not be executed natively on the system it was generated. Of course it > will not work, it was generated by a cross-compiler. > > I'm not saying that for some purposes it may be useful/nice to know the > "real" distribution that you are running, but not at the cost of breaking > the way testing and unstable work as twin distributions. Nothing is broken in the way testing and unstable work. Every other distribution manages to do this just fine, it's only Debian where this bug happens, and it's only because of this persistent refusal to fix base-files, despite the many bugs being reported over many years. > This means that no matter how much important it is for you to differentiate > them, you will have to achieve such functionality by other means other > than using os-release. And this is the bug. The purpose of os-release is to provide a universal, distro-agnostic way to do that differentiation. This is not something subjective or a personal preference: it's what the spec is for. The implementation of the spec in base-files is buggy. > At this point it should be noted that such functionality *already* existed > in the past in the lsb_release command, and it worked well enough. > The current maintainer does not seem to be willing to restore the > old behaviour, but nothing prevents the old code from being packaged > again under a new name in a new package that you can use for your intended > purpose. LSB is dead, and good riddance. We have os-release as the specification to identify images exactly because we want a cross-distribution, universal standard that doesn't require special scripts to exist and be run, but a simple metadata read-only text file. Adding yet again more Debian-specific ugly kludges is not a solution. > As far as base-files is concerned, the issue now is just how can I document > this properly in /usr/share/doc/base-files/FAQ so that people are really > aware that testing and unstable are sides of the same coin. It is not nice > to see non-bugs resurrected (as you did) because people did not understand > the reasons they are non-bugs. These are all base-files bugs, because they stop cross-distro software from being able to work. FAQs solve nothing. You cannot unilaterally modify a Linux-wide specification via a FAQ and call it a day, sorry, that is not how this works The implementation of the os-release spec in base-file is buggy and needs to be fixed. > There is already a paragraph about this in /usr/share/doc/base-files/FAQ. > Do you have any suggestion to improve it, so that we can avoid this > discussion in the future? > > Of maybe you would prefer to recycle this report and reassign it > as an ITP to create a package containing your desired script? > In this case I would gladly add a reference to the new package > in the FAQ once that such package exists. No, what I prefer to do now, given this is obviously going nowhere and it has been more than a decade of stonewalling on your part, resulting in a buggy implementation of a Linux-wide specification causing grief for Debian users, is escalating to the CTTE to override you.
