On Fri, 2 Aug 2024 at 11:39, Matthew Vernon <matt...@debian.org> wrote: > > Hi, > > With my jaunty TC member hat on, I would prefer if issue came to us with > a description of both sides' perspective on the discussion that they > would view as fair. In any case, I hope that Santiago will feel able to > chime in with their perspective.
In case that doesn't happen, for reference, his position is articulated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021663#55 and the other linked bugs. > My initial thought is that this is really about whether the base-files > maintainer is correct to have decided that os-release for testing and > unstable should not provide VERSION nor VERSION_ID; that seems to me the > technical policy question, and whether os-release moves into a new > package or not is an implementation detail that flows from that decision? Almost, but not quite - as mentioned in other emails it's actually fine to omit VERSION/VERSION_ID until release time. The main vector to do this distinction is VERSION_CODENAME which is currently set to 'trixie' in both trixie and sid. I am asking the CTTE to rule that testing and unstable must have different VERSION_CODENAME fields in their respective os-release files, that is to say "trixie" and "sid" respectively. It is correct to say that "sid does not have a version", just like Arch or Tumbleweed, so that is not a contentious point. It is acceptable to me to say "trixie does not have a version until release day", although I would prefer it did, because it is sufficient to have VERSION_CODENAME being different for the purpose of this ticket. Please note that older bugs against base-files mention version numbers because VERSION_CODENAME is a later addition to the spec, it appeared in 2016, so VERSION_ID used to be the only way to tell the difference between releases programmatically, so naturally users reporting bugs about being impossible to distinguish testing vs unstable asked for that to be added. It's no longer the case today, so this request is _not_ about overriding the decision to omit VERSION_ID until release date. > I think the submitter's contention against that is that in fact people > do want to be able to differentiate between testing and unstable. I > think they would go further and say that people want to be able to do > this without doing anything more involved than inspecting > /etc/os-release and that Debian should support them in so doing. Yes, this is correct, minus the part about the specific field numeric versions, which is more of a "nice to have" but can still be omitted if, e.g., RT prefers doing so.