tags 1021663 + moreinfo thanks [ Note: This comes from #675731. I'm replying here because this is where it really belongs ]
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. 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. Moreover, for some time, we had a smart "lsb_release" command which actually looked at the sources.list file (the recommended approach).
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.
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.
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. 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. [ 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 ]. 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. 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. 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. 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. 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. 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. 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. Thanks.
