On Sat, 3 Aug 2024 at 05:23, Sean Whitton <spwhit...@spwhitton.name> wrote: > > Hello, > > Luca is the upstream maintainer of the specification, but whether and > how the specification as published applies to Debian is not simply up to > his assertion.
To be really really precise, what I asserted is that the implementation is currently buggy in unstable, which is technically correct. I then _ask_ for a ruling to change the implementation. As already mentioned many times in other mails, one is perfectly allowed to say "this bug should not be fixed", "this bug's severity is nil", but not to say "this bug does not exist". To repeat the same example, if os-release was a program asserting on the state, it would run correctly on testing, and it would crash when run in unstable. One can say it's wrong that it crashes and one wants the state to remain as-is, but one can't say it doesn't crash, because it is a fact that it does, not an opinion. Both of these things can happen at the same time and be both true: the TC rules that the os-release file in unstable will remain as-is, and os-release implementation in Debian is buggy. A bug report can be closed by an upload that changes something, or by a close+wontfix. > The TC is being asked to override how Santiago has determined the > specification applies to Debian. > The Release Team's opinion is as relevant as Santiago's, I think. Everybody is welcomed to chime in at any time, and I have already said so on RT's IRC channel the other day just after opening this bug. On the matter of formal ownership however, I want to highlight that, as you can see in various replies detailing the precise technical solution that could possibly be implemented, there are _no changes to testing_ being proposed here, in case what you are worried about here is ownership of testing and changes to it. The only change would be in unstable, and as far as I understand (I might be wrong, please correct me) RT owns testing and [old]stable, not unstable. If you want to ensure the owner of the relevant area is directly involved, then perhaps it's the FTP team that should be, since as far as I understand they are the owners of unstable (might be wrong here too)? Again, everyone's welcome to chime in at any time, just trying to clarify who's responsible for what here. > Here is how it seems to me: > > - the specification applies cleanly to our stable releases, and we > want to support it, so we ship the appropriate metadata > > - it applies to testing during the later stages of the freeze, and > indeed we ship correct metadata at that time > > - it does not apply to testing the rest of the time, and it never > applies to unstable. We ship metadata, but only as a side-effect of > our process for preparing stable releases. > > If this is right, then the goal should not be to ship correct metadata > in testing and unstable, because that's impossible. > The goal should simply be to make whatever we ship in testing and > unstable relatively unobtrusive to users. If I understand correctly what you mean by "apply" here, and you mean in terms of the specification and what it is meant for, then as one of the owners of the spec I can say with certainty that the spec applies to testing and unstable, at any time. There is nothing incompatible with the way testing and unstable exist, are created, handled, maintained, used or anything else, and they are nothing "special" compared to other distributions, other than in the fact that the spec is not implemented correctly in unstable. There should not be any doubt on any of this, solely from the point of view of what the specification is for and what its goals are. One can of course disagree on whether it should be implemented as such and where, which is what is happening right now. If you mean it in terms of what is currently implemented in Debian, then that's also inaccurate: the spec is currently correctly implemented in testing, where it says VERSION_CODENAME=trixie at all times. It is incorrectly implemented in unstable, since also there it says VERSION_CODENAME=trixie, which makes it buggy, as sid is obviously not trixie, and that's the main change I am asking to implement. I'll note again that it is perfectly ok to omit VERSION_ID until release time, and in one of the replies I am clarifying that, if there are reasons to leave it out, it is ok to do so, and I am not asking the CTTE to overrule that. Also, speaking as someone who has worked on image building tools for many years, the current state is extremely intrusive for users, and that's why I am trying to fix it. > Possibly it's less obtrusive to always ship "trixie" in both testing and > unstable, rather than the special "trixie/sid" value. Or maybe not. > Santiago doesn't think so; it would be good to hear why, in this bug. > > I'd also like to note, in response to Luca, that it's misleading to say > that it's a frankendebian to have packages from sid installed on a > testing system, because that's how testing and sid are meant to work. > It's only a frankendebian to have packages from different suites > installed on stable. The implementation does not match what you are saying here though: $ sudo debootstrap testing foo/ <...> $ cat foo/etc/apt/sources.list deb http://deb.debian.org/debian testing main No trace whatsoever of 'unstable'. $ sudo debootstrap unstable bar/ <...> $ cat bar/etc/apt/sources.list deb http://deb.debian.org/debian unstable main No trace whatsoever of 'testing'. Is debootstrap buggy, then? If what you are saying is correct, then I should fix debootstrap to add apt sources for both testing and unstable, when one calls it with either "testing" or "unstable" or either codename, right?
