| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 21 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 28:51:56 |
| Calls: | 139 |
| Files: | 91 |
| Messages: | 42,690 |
Re: Luca Boccassi
The TL;DR is a request to override the base-files maintainer, and
enable moving os-release into a new, independent and separate source package, so that these bugs may finally be fixed, and Debian's os-
release may finally be made compliant with the specification.
If we are fixing that, we should also fix /etc/debian_version in the
same way. I've always been wondering why we don't put better content
into these files.
(Though I'm not sure the ruling should include the "move to new source package" part. It could also be fixed inside base-files.)
The TL;DR is a request to override the base-files maintainer, and
enable moving os-release into a new, independent and separate source
package, so that these bugs may finally be fixed, and Debian's os-
release may finally be made compliant with the specification.
There are several different ways of having different content in sid vs testing, and some have been proposed in the latest bug linked above, I
would be happy to discuss those details too if required.
Luca Boccassi <bluca@debian.org> writes:
There are several different ways of having different content in sid vs testing, and some have been proposed in the latest bug linked above, I would be happy to discuss those details too if required.
Generally the technical committee works best if it can consider a concrete technical proposal for a fix alongside the problem statement. I'm not a member, but as an interested bystander, I would like to see the details of precisely how you would implement your desired functionality. That could
be several options if you'd like the committee to choose between them.
I'd also like to see an elaboration of how you propose to distinguish sid from testing. This would be an ill-defined concept on the systems that I personally install testing packages on, and the specific criteria that you would use is not obvious to me from the bug discussion.
I did review the discussion #1021663 in the hope that I would find a
detailed technical proposal there, but your messages to that bug seemed to focus on criticisms of the current behavior mixed with insults. I wasn't able to find a proposal, but it's entirely possible I missed it.
I was about to say that the proposal is in the linked bug, but it has disappeared - it could be due to the bugs getting unlinked. Anyway, my variant is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54
There was also a slight variant by Gioele, that again I fail to find now
and it might be because of the bugs being rearranged, where testing-proposed-updates is used to upload testing-specific content.
So the identification will be as it is right now, it will depend on the version of the package providing the os-release file, which like any
other package can be manually overridden, upgraded, downgraded if one
really wishes to do so.
There are for sure a lot of criticisms of the bugs in base-files, but
there are no insults.
Luca Boccassi <bluca@debian.org> writes:
I was about to say that the proposal is in the linked bug, but it has disappeared - it could be due to the bugs getting unlinked. Anyway, my variant is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54
Ah, thank you. I think that answers my questions.
To summarize briefly to ensure that I understand, your proposal is to separate only this content into a second package, make base-files depend
on it, and then maintain different versions of that package in unstable
and testing.
There are two technical aspects of this proposal that worry me.
The first is adding a dependency to base-files. I know people have put a whole lot of work into pure dependency-based bootstrapping for Debian, but historically base-files has been very special and posed lots of
interesting complications that are separately handled in lots of different tools.
I do agree with Santiago's desire to maintain base-files as a "normal"
Debian package that gets tested in unstable and propagates to testing, so
if we go down this route, splitting out this data does seem better to me
than maintaining multiple lines of development for base-files itself.
The second thing that I'm not fond of is giving testing the version number
13 when we plan on using 13 as the version number for the trixie release.
I fear that if we do that, someone (probably a third-party package
provider) will add some workaround or behavior change for a package based
on that version number for a problem that only ever existed in testing and that was not in the actual 13 release. I would instead expect testing to
use some version number that is between stable and the version number that will be assigned to the next release, to reflect that it is likely to
change substantially before Debian makes an actual release 13.
(If I were designing this from scratch, I'd give serious thought to using even version numbers for releases and odd version numbers for testing, similar to how Perl releases are versioned for very similar reasons. But that's probably too big of a change for the level of benefit.)
Presumably the RELEASE_TYPE setting of pre-release is supposed to help
with that, but (a) that variable doesn't seem to be documented in os-release(5);
(b) the sorts of packagers that I'm worried about are quite
likely to not make subtle distinctions like that, so the version is still there as a potential foot-gun for people who aren't paying close
attention; and (c) I would argue that calling testing a "pre-release" is
not very accurate, since that applies that the contents are very similar
to the eventual release and are in a relatively late stage of testing.
There's a lot of merit to Santiago's decision to not give unstable a
version number that I think still applies to testing even when it's considered separately. However, you do have a good point that this makes life difficult for third-party packages that want to enforce a minimum version number because there's no way to then tell that, although this is
a testing release with no real version number, it does come after version
12. (Obviously this is not a great way to handle dependencies on a Debian release, and we probably wouldn't allow it in a regular Debian package,
but third-party packages often do things like this.) I'm not sure which
side of that trade-off I'd fall on, although I do think not having a
version number is more semantically correct given the current language documented in os-release(5). If RELEASE_TYPE were added to the spec with
an additional type of "development-snapshot" or something else more
accurate than "pre-release", that might change my mind, although my point
(b) above still applies.
There was also a slight variant by Gioele, that again I fail to find now and it might be because of the bugs being rearranged, where testing-proposed-updates is used to upload testing-specific content.
That seems like a better approach than the one proposed in the message
above, although I think it requires some manual intervention by the
release team. This doesn't seem like a serious problem given that uploads are presumably quite infrequent and the package is trivial.
This is an escalation requesting a ruling on the matter of several
base-files bugs around its buggy implementation of the os-release specification, the most recent example being #1021663 and other
instances that I could find with a cursory look being #1008735 and
#675731.
The TL;DR is a request to override the base-files maintainer, and
enable moving os-release into a new, independent and separate source
package, so that these bugs may finally be fixed, and Debian's os-
release may finally be made compliant with the specification.
Numerous attempts were independently made by many different people to
try and convince the base-files maintainer to fix this issue, the
oldest one linked above being 12 years ago, and they have all been
rejected, as recently as today. The only course of action left is
therefore asking for a CTTE intervention in the matter, as all attempts
at mediation and negotiation over the years have failed.
The os-release specification, of which I am an upstream author and maintainer, defines a distro-agnostic text-based metadata format to
allow identifying Linux distributions images, root directories, trees
and whatnot, without requiring distro-specific quirks, executables,
binaries, scripts or workarounds. It has been adopted pretty much
universally on Linux, including in Debian since 2012. It supersedes deprecated tools and specifications such as lsb_release and distro-
specific files such as debian_release.
Spec:
https://www.freedesktop.org/software/systemd/man/devel/os-release.html
With my upstream spec maintainer hat on, I am asserting that the base-
files implementation of the os-release specification is buggy. This has always been the case, since the very beginning, as it can be seen in
the oldest of the bugs linked above. The crux of the issue is that the
way base-files implements the specification does not allow to
distinguish testing vs unstable images, and worse than that, it
recently started providing wrong and misleading information,
incorrectly identifying sid as trixie (via VERSION_CODENAME=trixie).
This has resulted in numerous downstream users, tools, scripts and code having to employ fragile Debian-specific hacks, such as trying to grep /etc/apt/sources.list in an attempt to catch "unstable/sid" or
"testing" keywords, which of course is can break spectacularly, for
example if apt is not configure in an image (which is normal in a read-
only image-based system), or if both unstable and testing repositories
are present, with unstable pinned via apt-preferences to 1. Other distributions do not have this issue, it is only a problem that Debian
forces its users to deal with, causing grief and pain.
The base-files maintainer provides broadly two categories of
justifications for refusing to fix these issues. The first one is
dismissing any proposed solution as "ugly", without really
substantiating what it means - that is for example the case for
multiple proposals in #1021663. The second one is pushing forward a
philosophical explanation according to which testing and unstable are
not actually different images, but they are one and the same (two sides
of the same coin is the expression used). While that might be true in a philosophical sense, this is a practical matter, and it concerns only
the os-release specification and its implementation. In such context,
testing and unstable are different and independent images, built from different and independent archives of packages. For example, at any
point in time you can do:
deboostrap testing /tmp/a
deboostrap unstable /tmp/b
and if your shell history is lost, you have no reliable, stable, distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
These, created at the same time, contain different packages and refer
to different archives, so while from a philosophical point of view one
might make one argument or the other, from the very specific, concrete
and real issue of implementing the os-release specification, they are different releases and it must be possible to identify them as such,
and wrong information should not be conveyed to users.
There is also another common misunderstanding regarding what
constitutes a rolling release, sometimes used to justify avoiding to
fix these bugs. Again here such a concept from a philosophical point of
view might be bent into meaning many different things, but from the
point of view of the os-release specification, a rolling release is a
release that will never have a +1 or a -1 version. From the os-release
point of view, the fact that a distribution is updated often and gets a
lot of new packages, that might break ABI/API, or that is not security supported, does not mean it is a rolling distribution. So unstable/sid
is a rolling distribution, because there will never be a new version,
it will always be sid. Trixie however is _not_ a rolling distribution, because there is a trixie-1 (bookworm) and there will be a trixie+1
(forky). The fact that trixie gets a lot of changes in this 2 years development period is orthogonal and independent, and does not qualify
it as a rolling distribution, in the context of the os-release
specification. In fact, there is a proposal to add an independent os-
release field that qualifies a version as "stable", "lts" or in "development", that would be suited to mark testing as such. So it
would be entirely appropriate to set VERSION_ID=13 in trixie's os-
release right now. It is not appropriate to set VERSION_ID=13 in sid's os-release, now or ever.
These issues are not just theoretical, and do not concern mere personal preferences or cleanliness or code quality or ugliness. They cause very
real, very actual and very painful grief for Debian users, as evidenced
by the multiple independent bugs with multiple independent reporters
chiming in, and the multiple ugly hacks that have to be implemented as Debian-specific workarounds (the latest instance of which can be found atáhttps://sources.debian.org/src/systemd/256.4-2/debian/tests/upstream/#L15 ).
The base-files maintainer repeatedly, over numerous years, refused to
fix these incompatibilities with the specification, citing personal preferences and interpretations, and the latest suggestion as per
#1021663 is to override the lsb_releae maintainer and ship again buggy
and deprecated lsb_release python scripts to try again to solve the
problem in a Debian-specific way, parsing apt's sources.list. The point
of a cross-distro specification is to perform its function reliably so
that users do not have to employ distro-specific workarounds, so we are currently doing our users a disservice by shipping a buggy
implementation, and require them to use deprecated and buggy scripts as workarounds. It would in fact be much better to simply not ship an implementation of os-release at all, rather than implement it wrongly
based on reinterpretations.
A concrete proposal that I can put forward is to move os-release away
from base-files, into a new source+binary package, that can be managed independently, and can be updated to respect the specification it is
supposed to follow. base-files ships code in maintainer scripts so
requires changes and updates, and using a separate package allows to do
only one upload per cycle to set the new metadata. base-files can then
depend on this new binary package, which will ship only /usr/lib/os-
release, its /etc/os-release symlink and no maintainer script. This
package should be team-maintained on Salsa (as opposed as base-files
that is individually maintained with no VCS).
The os-release installed in sid's images would then be something along
those lines:
PRETTY_NAME="Debian GNU/Linux sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=sid
ID=debian
And trixie's would be something along those lines:
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
RELEASE_TYPE=pre-release
ID=debian
With RELEASE_TYPE= changing to 'lts' immediately before release day.
There are several different ways of having different content in sid vs testing, and some have been proposed in the latest bug linked above, I
would be happy to discuss those details too if required.
I volunteer to do the work to create and team-maintain the new package,
and provide a patch to do the move from base-files. If requested, I am
happy to do such work in advance so that you can judge based on
something concrete.
Hi Luca,
On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
This is an escalation requesting a ruling on the matter of several base-files bugs around its buggy implementation of the os-release specification, the most recent example being #1021663 and other
instances that I could find with a cursory look being #1008735 and
#675731.
I observe that Santiago has replied to each of them with patience and
that he has presented relatable reasons for his choices.
As you detail later, it seems that the corner stone of your complaint is
that an unstable installation should have VERSION_CODENAME=sid rather
than VERSION_CODENAME=trixie. Do you agree with this characterization?
The TL;DR is a request to override the base-files maintainer, and
enable moving os-release into a new, independent and separate source package, so that these bugs may finally be fixed, and Debian's os-
release may finally be made compliant with the specification.
On a process level, the CTTE can only decide among available options. In
this context available roughly equates the existence of a patch (or
source package). Reading multiple bugs, I found disagreement on this approach, but no code that could be characterized as a reviewable
solution.
Another plausible way to interpret your mail is that you really ask the
CTTE to override the base-files maintainer in claiming ownership of /etc/os-release in the base-files package request releasing the file to another package. Given that said file has become part of the essential interface, releasing it is subtle and warrants a more detailed look at
how the take-over is supposed to happen. To me that process is too
sketchy to consider at this time.
Numerous attempts were independently made by many different people to
try and convince the base-files maintainer to fix this issue, the
oldest one linked above being 12 years ago, and they have all been rejected, as recently as today. The only course of action left is
therefore asking for a CTTE intervention in the matter, as all attempts
at mediation and negotiation over the years have failed.
Evidently, there are multiple conflicting requirements that various
parties would like to see implemented. The base-files maintainer has
made a compromise and argued in favour of his position. Said compromise encompasses an interpretation of the os-release specification that does
not follow it to the letter.
The os-release specification, of which I am an upstream author and maintainer, defines a distro-agnostic text-based metadata format to
allow identifying Linux distributions images, root directories, trees
and whatnot, without requiring distro-specific quirks, executables, binaries, scripts or workarounds. It has been adopted pretty much universally on Linux, including in Debian since 2012. It supersedes deprecated tools and specifications such as lsb_release and distro- specific files such as debian_release.
Spec:
https://www.freedesktop.org/software/systemd/man/devel/os-release.html
With my upstream spec maintainer hat on, I am asserting that the base- files implementation of the os-release specification is buggy. This has always been the case, since the very beginning, as it can be seen in
the oldest of the bugs linked above. The crux of the issue is that the
way base-files implements the specification does not allow to
distinguish testing vs unstable images, and worse than that, it
recently started providing wrong and misleading information,
incorrectly identifying sid as trixie (via VERSION_CODENAME=trixie).
Please allow me to raise the question of what is the benefit of differentiating sid and trixie in /etc/os-release. I am inclined to
agree that VERSION_CODENAME would be technically wrong in unstable, but
we have a history of sometimes bending rules.
Conversely, I am unsure how to distinguish testing and unstable myself.
Say I operate an unstable system and eventually decide that my ride is
too bumpy and I prefer running testing, I may edit my sources.list and
after a month or so my system will have reasonably converged to testing.
At what point would my /etc/os-release change?
Russ raised the question of how to represent a testing system that pulls
some packages from unstable.
This has resulted in numerous downstream users, tools, scripts and code having to employ fragile Debian-specific hacks, such as trying to grep /etc/apt/sources.list in an attempt to catch "unstable/sid" or
"testing" keywords, which of course is can break spectacularly, for
example if apt is not configure in an image (which is normal in a read- only image-based system), or if both unstable and testing repositories
are present, with unstable pinned via apt-preferences to 1. Other distributions do not have this issue, it is only a problem that Debian forces its users to deal with, causing grief and pain.
Given the issues you experienced, would you be kind enough to reference
some of them here?
The base-files maintainer provides broadly two categories of
justifications for refusing to fix these issues. The first one is dismissing any proposed solution as "ugly", without really
substantiating what it means - that is for example the case for
multiple proposals in #1021663. The second one is pushing forward a
As far as I grasped from reading the bugs there are roughly two solution categories. One continues to install /etc/os-release as a conffile and
uses the t-p-u mechanism to update it in trixie. The other category
turns it into a configuration file constructing it from some maintainer script. I can relate to characterizing both as ugly.
With my CTTE member hat lifted, I may also participate in design
discussions and would like to propose a third alternative (although it
might have been mentioned in the parts that I skimmed too quickly and
hope that you can point to the earlier discussion in that case).
Consider adding a new Debian binary package containing /etc/os-release
with contents suitable for unstable. This package would use the
dpkg-divert mechanism to avoid a conflict with base-files which would continue to install /etc/os-release with contents suitable for testing
(even in unstable). We would mark this new package "Essential: yes",
but have no other package depend on it. We would also file a permanent
rc-bug to prevent it from migrating to testing. As a result, the set of essential packages as discovered by bootstrapping tools would differ
between testing and unstable and the /etc/os-release would be diverted
for unstable only. A significant downside of this approach is that all existing unstable systems would never install this package (and thus
continue to be seen as testing installations) and all systems that were bootstrapped as unstable would be keep this package even if they were to
be downgraded to testing at a later time (unless the administrator
actively removes the new package).
philosophical explanation according to which testing and unstable are
not actually different images, but they are one and the same (two sides
of the same coin is the expression used). While that might be true in a philosophical sense, this is a practical matter, and it concerns only
the os-release specification and its implementation. In such context, testing and unstable are different and independent images, built from different and independent archives of packages. For example, at any
point in time you can do:
deboostrap testing /tmp/a
deboostrap unstable /tmp/b
and if your shell history is lost, you have no reliable, stable, distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
These, created at the same time, contain different packages and refer
to different archives, so while from a philosophical point of view one might make one argument or the other, from the very specific, concrete
and real issue of implementing the os-release specification, they are different releases and it must be possible to identify them as such,
and wrong information should not be conveyed to users.
We have a disagreement about whether the information you intend to
convey actually exists beyond the point in time where you deboostrap. If
I debootstrap unstable and look at it a week later, it more closely represents testing than unstable.
There is also another common misunderstanding regarding what
constitutes a rolling release, sometimes used to justify avoiding to
fix these bugs. Again here such a concept from a philosophical point of view might be bent into meaning many different things, but from the
point of view of the os-release specification, a rolling release is a release that will never have a +1 or a -1 version. From the os-release point of view, the fact that a distribution is updated often and gets a
lot of new packages, that might break ABI/API, or that is not security supported, does not mean it is a rolling distribution. So unstable/sid
is a rolling distribution, because there will never be a new version,
it will always be sid. Trixie however is _not_ a rolling distribution, because there is a trixie-1 (bookworm) and there will be a trixie+1 (forky). The fact that trixie gets a lot of changes in this 2 years development period is orthogonal and independent, and does not qualify
it as a rolling distribution, in the context of the os-release specification. In fact, there is a proposal to add an independent os- release field that qualifies a version as "stable", "lts" or in "development", that would be suited to mark testing as such. So it
would be entirely appropriate to set VERSION_ID=13 in trixie's os-
release right now. It is not appropriate to set VERSION_ID=13 in sid's os-release, now or ever.
Conversely, we might consider that the os-release specification that is
meant to cover the various aspects of Linux distributions is a poor fit
for Debian and that its expressiveness is too limited to accurately
represent the migration-based approach that Debian uses to assemble its releases. We might consider this a bug in the os-release specification
and we may even disagree with the os-release specification upstream (aka
you) about that. It all depends on how you look at it.
These issues are not just theoretical, and do not concern mere personal preferences or cleanliness or code quality or ugliness. They cause very real, very actual and very painful grief for Debian users, as evidenced
by the multiple independent bugs with multiple independent reporters chiming in, and the multiple ugly hacks that have to be implemented as Debian-specific workarounds (the latest instance of which can be found
at https://sources.debian.org/src/systemd/256.4-2/debian/tests/upstream/#L15
).
Thank you for referencing a practical effect. It is not clear how mkosi
uses the Release field and why it is important to differentiate testing
from unstable though.
The base-files maintainer repeatedly, over numerous years, refused to
fix these incompatibilities with the specification, citing personal preferences and interpretations, and the latest suggestion as per
#1021663 is to override the lsb_releae maintainer and ship again buggy
and deprecated lsb_release python scripts to try again to solve the
problem in a Debian-specific way, parsing apt's sources.list. The point
of a cross-distro specification is to perform its function reliably so
that users do not have to employ distro-specific workarounds, so we are currently doing our users a disservice by shipping a buggy
implementation, and require them to use deprecated and buggy scripts as workarounds. It would in fact be much better to simply not ship an implementation of os-release at all, rather than implement it wrongly
based on reinterpretations.
As far as I read the specification, no field is mandatory. This gives
rise to another solution to come into compliance with the letter of the specification: Drop the VERSION_CODENAME from /etc/os-release just as
the VERSION is already dropped. As far as I can see, all other fields
have compliant values.
A concrete proposal that I can put forward is to move os-release away
from base-files, into a new source+binary package, that can be managed independently, and can be updated to respect the specification it is supposed to follow. base-files ships code in maintainer scripts so
requires changes and updates, and using a separate package allows to do only one upload per cycle to set the new metadata. base-files can then depend on this new binary package, which will ship only /usr/lib/os- release, its /etc/os-release symlink and no maintainer script. This
package should be team-maintained on Salsa (as opposed as base-files
that is individually maintained with no VCS).
The os-release installed in sid's images would then be something along those lines:
PRETTY_NAME="Debian GNU/Linux sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=sid
ID=debian
And trixie's would be something along those lines:
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
RELEASE_TYPE=pre-release
ID=debian
With RELEASE_TYPE= changing to 'lts' immediately before release day.
There are several different ways of having different content in sid vs testing, and some have been proposed in the latest bug linked above, I would be happy to discuss those details too if required.
I think this needs agreement from the release team before moving
forward.
With my bootstrapping-hat, I would also like to see evidence of tests
that this approach does not negatively impact debootstrap-like tools.
(Russ gave a longer rationale on this, thanks.)
I volunteer to do the work to create and team-maintain the new package,
and provide a patch to do the move from base-files. If requested, I am happy to do such work in advance so that you can judge based on
something concrete.
Thank you for the offer. Before asking you to do that work, I think
there are a few actionable items for moving the disagreement forward:
I'd like to better understand the problems caused by the imprecise implementation of the os-release specification as that aspect is still
quite sketchy in your request.
Your request actually includes a number of possible solutions with
varying implications. Could you rank the various solutions according to
your preference and express your reasons for ranking when it is not
obvious?
It could be a dependency of something else, or it could be marked as essential itself, given the content is a 5 lines text file and a symlink
it shouldn't be too hard to figure out an acceptable way to ensure it
ships everywhere. It doesn't have to be related to base-files at all, it
was just the first thing that came to mind.
The really important part is adding different and separate codenames, so
that a testing image can be reliably and univocally distinguished from a
sid image, and VERSION_CODENAME is enough for that, the version number
is cherry on top.
But this example seems a bit too tortured to me.
And secondly, that same strawman
can be applied to stable, as we do point releases and security uploads.
What do you mean?!! It's right there! https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
...ok, ok, it's there now because I just merged it and regenerated the
docs :-P
The TL;DR: ensure that the version of the 'os-release' package with
the content for unstable stays in unstable and never migrates, and the version of the 'os-release' package with the content for testing goes
to testing either via a quick migration or via
testing-proposed-updates.
That's it. Of course if what you are saying is that you mix and match
a selection of packages from testing and unstable, well that's a frankendebian - you can do that on any release (I have some testing
packages pulled in my debian stable laptop right now).
I could echo "ID=windows 3.1" into my local
/etc/os-release and nothing would stop me or fix it until the next
stable release.
The second thing that I'm not fond of is giving testing the version number
13 when we plan on using 13 as the version number for the trixie release.
I fear that if we do that, someone (probably a third-party package
provider) will add some workaround or behavior change for a package based
on that version number for a problem that only ever existed in testing and that was not in the actual 13 release. I would instead expect testing to
use some version number that is between stable and the version number that will be assigned to the next release, to reflect that it is likely to
change substantially before Debian makes an actual release 13.
(If I were designing this from scratch, I'd give serious thought to using even version numbers for releases and odd version numbers for testing, similar to how Perl releases are versioned for very similar reasons. But that's probably too big of a change for the level of benefit.)
Presumably the RELEASE_TYPE setting of pre-release is supposed to help
with that, but (a) that variable doesn't seem to be documented in os-release(5); (b) the sorts of packagers that I'm worried about are quite likely to not make subtle distinctions like that, so the version is still there as a potential foot-gun for people who aren't paying close
attention; and (c) I would argue that calling testing a "pre-release" is
not very accurate, since that applies that the contents are very similar
to the eventual release and are in a relatively late stage of testing.
There's a lot of merit to Santiago's decision to not give unstable a
version number that I think still applies to testing even when it's considered separately.
There was also a slight variant by Gioele, that again I fail to find now and it might be because of the bugs being rearranged, where testing-proposed-updates is used to upload testing-specific content.
That seems like a better approach than the one proposed in the message
above, although I think it requires some manual intervention by the
release team. This doesn't seem like a serious problem given that uploads are presumably quite infrequent and the package is trivial.
Conversely, I am unsure how to distinguish testing and unstable myself.
Say I operate an unstable system and eventually decide that my ride is
too bumpy and I prefer running testing, I may edit my sources.list and
after a month or so my system will have reasonably converged to testing.
At what point would my /etc/os-release change?
Russ raised the question of how to represent a testing system that pulls
some packages from unstable.
This has resulted in numerous downstream users, tools, scripts and code having to employ fragile Debian-specific hacks, such as trying to grep /etc/apt/sources.list in an attempt to catch "unstable/sid" or
"testing" keywords, which of course is can break spectacularly, for
example if apt is not configure in an image (which is normal in a read- only image-based system), or if both unstable and testing repositories
are present, with unstable pinned via apt-preferences to 1. Other distributions do not have this issue, it is only a problem that Debian forces its users to deal with, causing grief and pain.
Given the issues you experienced, would you be kind enough to reference
some of them here?
We have a disagreement about whether the information you intend to
convey actually exists beyond the point in time where you deboostrap. If
I debootstrap unstable and look at it a week later, it more closely represents testing than unstable.
Conversely, we might consider that the os-release specification that is
meant to cover the various aspects of Linux distributions is a poor fit
for Debian and that its expressiveness is too limited to accurately
represent the migration-based approach that Debian uses to assemble its releases. We might consider this a bug in the os-release specification
and we may even disagree with the os-release specification upstream (aka
you) about that. It all depends on how you look at it.
As far as I read the specification, no field is mandatory. This gives
rise to another solution to come into compliance with the letter of the specification: Drop the VERSION_CODENAME from /etc/os-release just as
the VERSION is already dropped. As far as I can see, all other fields
have compliant values.
I'd like to better understand the problems caused by the imprecise implementation of the os-release specification as that aspect is still
quite sketchy in your request.
The second [objection from the base-files maintainer] is pushing forward a philosophical explanation according to which testing and unstable are
not actually different images, but they are one and the same (two sides
of the same coin is the expression used). While that might be true in a philosophical sense, this is a practical matter, and it concerns only
the os-release specification and its implementation. In such context,
testing and unstable are different and independent images, built from different and independent archives of packages. For example, at any
point in time you can do:
deboostrap testing /tmp/a
deboostrap unstable /tmp/b
and if your shell history is lost, you have no reliable, stable, distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
I just know that I've seen a lot of code that uses version
numbers or code names this way, mostly in things like Puppet rules. Most
of the time people will probably get this right, but there are some
obvious potential mistakes such as coding a condition that says 13 behaves the same as 12 (but the eventual release won't) or that 13 always behaves
in some new way (but testing systems that weren't upgraded to the released version 13 don't and instead behave like 12).
The most mistake-resistant approach would be to give
testing some *other* code name that isn't trixie, and only give the code
name of trixie at the time of release, but that's also weirdly different
from how we use codenames in the archive structure
Luca Boccassi <bluca@debian.org> writes:
It could be a dependency of something else, or it could be marked as essential itself, given the content is a 5 lines text file and a symlink
it shouldn't be too hard to figure out an acceptable way to ensure it
ships everywhere. It doesn't have to be related to base-files at all, it was just the first thing that came to mind.
Given that it's included in base-files now and base-files is essential, I believe it has to continue to be provided by an essential package, unless
we want to try to do the work of figuring out if os-release can be removed from essential (and I would not be eager to do that).
Since it is part of the essential set, though, I'm not sure the dependency from base-files is actually needed (but also it may not really matter). I think dependencies between essential packages are only really used during
the bootstrapping phase, and presumably os-release is not needed by bootstrapping.
Anyway, I haven't done any work in this area of Debian so I'll leave this
for other people with more relevant expertise to comment on.
[version numbers]
The really important part is adding different and separate codenames, so that a testing image can be reliably and univocally distinguished from a sid image, and VERSION_CODENAME is enough for that, the version number
is cherry on top.
Like Santiago, I admit to not finding this use case compelling. Most of
the reasons why I might imagine someone would want to do this sound like misunderstandings of how Debian works, given that in many cases, excluding the apt configuration, today's unstable image is next week's testing image without changing a single byte on disk. In other words, in the cases
where this does make sense, I feel like this desire is usually a proxy for "what package pool will *new* packages for this image be drawn from," and using os-release to guess at that information seems at least a bit questionable. If what someone cares about is apt configuration, it seems better to get that information from apt directly, not via a fallible proxy (and maybe we need a better way to do that).
However, it doesn't seem obviously *bad* to do this either, and I trust
that you have reasons why you think this is important.
But this example seems a bit too tortured to me.
Well, it's related to your example of the zoom package basing decisions on the version number. If they had done that based on a version number of testing, there's a fairly high chance that whatever decisions they made
would be wrong by the time the stable release happens, particularly if
they do that early in a release cycle.
That said, I would expect most third-party non-free packages like that to
not care at all about anything in Debian until it reached stable, so the chances of them doing that may be low.
And secondly, that same strawman
straw man (noun)
1: a weak or imaginary opposition (such as an argument or adversary)
set up only to be easily confuted
This is the sort of thing I was talking about when I said insults. I'm
not sure if you're using this term with some non-standard definition (believable, since I was using this argument in the opposite way from how
one would use a straw man), but the normal implication of calling my
argument a straw man is that I was arguing in bad faith. This comes
across as weirdly aggressive and makes these discussions unnecessarily annoying.
can be applied to stable, as we do point releases and security uploads.
I am surprised that point releases don't change VERSION_ID, and now I'm curious why that's the case. I was assuming, having not previously looked
at it, that VERSION_ID would match /etc/debian_release, but I see that it doesn't and has only the major version.
Regardless, security uploads do potentially create this problem, but we
also try pretty hard to not change major functionality in security uploads
in ways that may prompt someone to want to change behavior based on that version. There is a window of possibility there, I think it's
sufficiently narrow to not worry that much about. It's at least a much narrower problem than version numbers in testing.
I'm not sure how important this is, and all the options have obvious problems. I just know that I've seen a lot of code that uses version
numbers or code names this way, mostly in things like Puppet rules. Most
of the time people will probably get this right, but there are some
obvious potential mistakes such as coding a condition that says 13 behaves the same as 12 (but the eventual release won't) or that 13 always behaves
in some new way (but testing systems that weren't upgraded to the released version 13 don't and instead behave like 12).
On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
I could echo "ID=windows 3.1" into my local
/etc/os-release and nothing would stop me or fix it until the next
stable release.
Not even automatically. /etc/os-release is a conffile, isnt it?
Given that it's included in base-files now and base-files is essential, I believe it has to continue to be provided by an essential package, unless
we want to try to do the work of figuring out if os-release can be removed from essential (and I would not be eager to do that).
Since it is part of the essential set, though, I'm not sure the dependency from base-files is actually needed (but also it may not really matter). I think dependencies between essential packages are only really used during
the bootstrapping phase, and presumably os-release is not needed by bootstrapping.
On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
The second [objection from the base-files maintainer] is pushing forward a philosophical explanation according to which testing and unstable are
not actually different images, but they are one and the same (two sides
of the same coin is the expression used). While that might be true in a philosophical sense, this is a practical matter, and it concerns only
the os-release specification and its implementation. In such context, testing and unstable are different and independent images, built from different and independent archives of packages. For example, at any
point in time you can do:
deboostrap testing /tmp/a
deboostrap unstable /tmp/b
and if your shell history is lost, you have no reliable, stable, distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
But, let's continue your example: suppose you ran those commands back in January. Now, 6 months later, run similar commands again:
debootstrap testing /tmp/c
debootstrap unstable /tmp/d
With your proposed labelling of testing and unstable as being fundamentally different, you would have:
/tmp/a: testing from January, labelled as testing (or trixie or Debian 13) /tmp/b: unstable from January, labelled as unstable
/tmp/c: testing from July, labelled as testing (or trixie or Debian 13) /tmp/d: unstable from July, labelled as unstable
But, contrary to that, the differences between a and b will be relatively small, and so will the differences between c and d; whereas the differences between a and c will be large (even though they're both labelled as
testing) and so will the differences between b and d.
For example, a and b will have glibc 2.37, but c and d will have 2.39,
with whatever behaviour changes have happened in the last 6 months. Similarly, neither a nor b has been through the t64 transition, but
both c and d have.
I think the most important fact about all of these chroots is
"it's strictly newer than Debian 12, so expect some behaviour
changes". Precisely how much newer, and precisely which behaviour changes,
is not such a simple question to answer: it depends which package's
behaviour you're interested in, and if you want to answer that question,
the only way is to look at individual packages, so that you can tell
whether they were last updated in January or whether they have been
updated to July's version.
The closest equivalent of what Fedora and Ubuntu do would be to label
both testing and unstable as though they were some sort of Debian 13 prerelease, but not distinguish between the two. But Luca is asking for unstable images/chroots/installations to be machine-readably different,
even if they happen to contain all of the same packages at the same
versions (other than base-files), and I think that's because unstable
has more users than Ubuntu proposed, and is typically further away from testing than the gap between Ubuntu proposed and devel.
So I think Luca really has two distinct change requests here, not just one:
1. Label testing as Debian 13 starting from the beginning of the trixie
cycle, and the equivalent for each future cycle
2. Label unstable as something that differs from testing
and it would be technically possible to have both, or neither, or accept
(1.) but reject (2.).
I personally have a lot of sympathy for wanting (1.) - as I said, when
I'm communicating with developers outside the Debian bubble who don't
know our processes, I tend to refer to both testing and unstable as some
sort of prerelease, alpha or preview of Debian 13, because that's close enough to true. I am much more hesitant about (2.), because testing and unstable are more similar than they are different, and more similar to
each other than they are to their state 6 months ago.
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.
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?
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.
To further clarify why the status quo with VERSION_CODENAME=trixie in
sid is really bad: it used to be that if you had "debian" mentioned in os-release but no other version identifying fields, you knew you were
on testing OR unstable and you'd have to deploy horrendous hacks to
attempt and figure out which of the two it was really.
Sorry, but there's no other way to define this than a bug.
VERSION_CODENAME=trixie was added, and the problem as explained is
that it's present in sid too. So the only identifier we have in sid, identifies it as trixie, which is categorically and unequivocally
wrong.
On Fri, 2 Aug 2024 at 10:15, Simon McVittie <smcv@debian.org> wrote:
So I think Luca really has two distinct change requests here, not just one:
1. Label testing as Debian 13 starting from the beginning of the trixie
cycle, and the equivalent for each future cycle
2. Label unstable as something that differs from testing
and it would be technically possible to have both, or neither, or accept (1.) but reject (2.).
I personally have a lot of sympathy for wanting (1.) - as I said, when
I'm communicating with developers outside the Debian bubble who don't
know our processes, I tend to refer to both testing and unstable as some sort of prerelease, alpha or preview of Debian 13, because that's close enough to true. I am much more hesitant about (2.), because testing and unstable are more similar than they are different, and more similar to
each other than they are to their state 6 months ago.
1 is already the case, and actually I am asking to revert that. VERSION_CODENAME=trixie was added, and the problem as explained is
that it's present in sid too. So the only identifier we have in sid, identifies it as trixie, which is categorically and unequivocally
wrong.
On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
VERSION_CODENAME=trixie was added, and the problem as explained is
that it's present in sid too. So the only identifier we have in sid, identifies it as trixie, which is categorically and unequivocally
wrong.
When involved in a disagreement, please could you try to make an effort
to understand the point of view of the other side, rather than declaring
them to be categorically and unequivocally wrong? I think that would
lead to fewer people feeling that they're being shouted at and refusing
to engage with you, which is likely to result in more of the changes
you want to see actually being adopted.
In this case, I think the two design principles might be:
- you think of sid as an independent rolling-release distribution in
its own right, an alternative to e.g. Arch Linux, and so you want to
label sid images/containers/chroots/etc. in a way that is consistent
with that point of view;
- Santiago thinks of sid as a tool to be used as part of the process of
making our next stable release, an alternative to e.g. Fedora Rawhide,
and wants to label sid images/etc. in a way that is consistent with
*that* point of view
I think that, as a project, we need a lot more willingness to frame disagreements in terms of "I see your point, but I think my point is
more important", and a lot less "you're just wrong". All of us are
doing our best to make Debian the best possible Free operating system,
even if we don't always agree on precisely what that means.
On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
To further clarify why the status quo with VERSION_CODENAME=trixie in
sid is really bad: it used to be that if you had "debian" mentioned in os-release but no other version identifying fields, you knew you were
on testing OR unstable and you'd have to deploy horrendous hacks to
attempt and figure out which of the two it was really.
OK, I think this is progress:
What is the scenario / use-case in which it becomes necessary to
distinguish between those two suites?
To put that another way, what external piece of software needs to
change its behaviour, dependent on whether you are running testing
(of an unspecified datestamp) or unstable (of an unspecified datestamp)?
Or perhaps you are thinking of a scenario in which a *person* needs to
change their behaviour, dependent on whether they are running testing
or unstable?
Sorry, but there's no other way to define this than a bug.
I would personally characterize it as a potential root cause for bugs,
more than as a bug itself. To me, an example of one of those bugs might
look more like "I run ansible/Puppet/etc. against my test VM, and I
expect it to do a useful thing, but actually it..." (with the buggy result perhaps being to crash, or to install the wrong package, or something).
Hi Russ,essential, I
Let me adress the essential/bootstrap aspects of this sub-discussion
only.
On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
Given that it's included in base-files now and base-files is
unlessbelieve it has to continue to be provided by an essential package,
removedwe want to try to do the work of figuring out if os-release can be
dependencyfrom essential (and I would not be eager to do that).
I concur.
Since it is part of the essential set, though, I'm not sure the
matter). Ifrom base-files is actually needed (but also it may not really
duringthink dependencies between essential packages are only really used
packagesthe bootstrapping phase, and presumably os-release is not needed by bootstrapping.
It actually is the other way round. debootstrap-like tools will
automatically pick up all packages marked with "Essential: yes".
Bootstrapped systems will not magically install newly essential
though. So doing an upload of base-files that releases /etc/os-release
will not magically cause a newly essential os-release package to beessential
installed and thus our essential promise of /etc/os-release may be temporarily broken. (There is no implication of how bad breaking this
promise is.) So whenever we want to add a new package to the
set, we need some existing essential package to declare a dependencyon
that new package for the duration of one release cycle (as we do notfiles
support skip upgrades).
The obvious candidate to express such a dependency would be base-
here and that brings us back to the aspects you (Russ) mentionedearlier
regarding the fragility of the bootstrap order related to base-files. Admittedly, bootstrapping is more empirically solved in Debian than well-defined. As I attempted clarifying this in Debian policyearlier,
the outcome was to explicitly leave it undefined. If I rememberorder
correctly, randomly ordering the maintainer scripts executed during filesystem bootstrap makes things fail every now and then and the
that most tools produce works well enough currently. Any newdependency
inside the essential set poses a risk of perturbing this order thatbefore
happens to work by chance. Hence my request to validate the proposed changes. With luck, things just work, but we better figure out
we upload to unstable.mostly
This is not pretty, but it is what we have. And then I see this
as a work item rather than a blocking issue once we agree on theother
matters.
That's yet another Debian-specific workaround. The point of this is,
again, answering the question "what is this vendor tree" _without_
distro specific kludges. That's the entire reason for os-release to
exist. If the answer at any point is "check os-release AND THEN run this distro specific set of scripts or binaries", then the answer is wrong,
and the implementation of the spec is buggy. Again, one might say "I am
ok with this being buggy because we gain X Y and Z in exchange", but
buggy it is and buggy it will remain.
On Fri, 2 Aug 2024 at 04:00, Russ Allbery <rra@debian.org> wrote:
Well, it's related to your example of the zoom package basing decisions
on the version number. If they had done that based on a version number
of testing, there's a fairly high chance that whatever decisions they
made would be wrong by the time the stable release happens,
particularly if they do that early in a release cycle.
That said, I would expect most third-party non-free packages like that
to not care at all about anything in Debian until it reached stable, so
the chances of them doing that may be low.
Uh, I did not provide an example regarding zoom? Where's that from?
I am surprised that point releases don't change VERSION_ID, and now I'm
curious why that's the case. I was assuming, having not previously
looked at it, that VERSION_ID would match /etc/debian_release, but I
see that it doesn't and has only the major version.
It is correct as-is. VERSION_ID is meant to identify a release, not
updates or point releases. A release as in, Debian Bookworm, or Fedora
40, or Ubuntu Noble, and so on.
Regardless, security uploads do potentially create this problem, but we
also try pretty hard to not change major functionality in security
uploads in ways that may prompt someone to want to change behavior
based on that version. There is a window of possibility there, I think
it's sufficiently narrow to not worry that much about. It's at least a
much narrower problem than version numbers in testing.
See other mail. It is really not narrow at all, because of kernel
upstream LTS updates. The upstream kernel quality of these branches is really, really low, and massive regressions sneak in at all times. The difference of behaviour between point releases is huge.
Debian stable updates do not, and pretty much never have, include only security fixes.
Luca Boccassi <bluca@debian.org> writes:
It is correct as-is. VERSION_ID is meant to identify a release, not
updates or point releases. A release as in, Debian Bookworm, or Fedora
40, or Ubuntu Noble, and so on.
Why would you not want to identify point releases? This really surprises
me.
Luca Boccassi <bluca@debian.org> writes:
That's yet another Debian-specific workaround. The point of this is,
again, answering the question "what is this vendor tree" _without_
distro specific kludges. That's the entire reason for os-release to
exist. If the answer at any point is "check os-release AND THEN run this distro specific set of scripts or binaries", then the answer is wrong,
and the implementation of the spec is buggy. Again, one might say "I am
ok with this being buggy because we gain X Y and Z in exchange", but
buggy it is and buggy it will remain.
This talk about "buggy" and "workarounds" didn't help me understand what
you meant, but I think what you're saying is that I'm right, you *do* only care about the apt configuration, BUT apt is Debian-specific and figuring
out how it is configured is not something that can be done portably, so
you do want to use os-release as a proxy for that information because it's
a cross-distro tool.
That makes sense to me. It's a fallible proxy and it will get a bunch of edge cases wrong, but it's probably not possible to do better with an equivalently simple tool.
Fundamentally, you want to change Debian's policy about testing to
complete the separation from unstable and treat it as a first-class
release in its own right in our metadata. Debian has historically not
done this and generally discouraged people from doing this (this is *not* just Santiago's position; Santiago is correctly reflecting the previous consensus of the project), but there's always been a fair bit of
controversy over that point, and I personally tend towards the side that thinks testing can be usefully treated as a rolling release with very substantial caveats and limitations.
I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.
On Fri, 2 Aug 2024 at 04:00, Russ Allbery <rra@debian.org> wrote:
Well, it's related to your example of the zoom package basing decisions
on the version number. If they had done that based on a version number
of testing, there's a fairly high chance that whatever decisions they
made would be wrong by the time the stable release happens,
particularly if they do that early in a release cycle.
That said, I would expect most third-party non-free packages like that
to not care at all about anything in Debian until it reached stable, so
the chances of them doing that may be low.
Uh, I did not provide an example regarding zoom? Where's that from?
Ugh, I'm sorry, I was reading a lot of bug history and completely misattributed that message (and, for that matter, when it was sent). I
was thinking of:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91
which was from Kipp Cannon. My apologies for the confusion.
I am surprised that point releases don't change VERSION_ID, and now I'm
curious why that's the case. I was assuming, having not previously
looked at it, that VERSION_ID would match /etc/debian_release, but I
see that it doesn't and has only the major version.
It is correct as-is. VERSION_ID is meant to identify a release, not
updates or point releases. A release as in, Debian Bookworm, or Fedora
40, or Ubuntu Noble, and so on.
Why would you not want to identify point releases? This really surprises
me.
Regardless, security uploads do potentially create this problem, but we
also try pretty hard to not change major functionality in security
uploads in ways that may prompt someone to want to change behavior
based on that version. There is a window of possibility there, I think
it's sufficiently narrow to not worry that much about. It's at least a
much narrower problem than version numbers in testing.
See other mail. It is really not narrow at all, because of kernel
upstream LTS updates. The upstream kernel quality of these branches is really, really low, and massive regressions sneak in at all times. The difference of behaviour between point releases is huge.
I believe kernels are usually (not always, but usually) updated as part of point releases, which is yet another reason why I am so baffled as to why
the VERSION_ID would not track point releases.
On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
Luca Boccassi <bluca@debian.org> writes:
It is correct as-is. VERSION_ID is meant to identify a release, not
updates or point releases. A release as in, Debian Bookworm, or Fedora
40, or Ubuntu Noble, and so on.
Why would you not want to identify point releases? This really
surprises me.
I think the idea is that two releases have a different VERSION_ID if and
only if they can both be fully up to date, but still remain
different. If we make the analogy of git, VERSION_ID labels a branch,
not a tag.
Simon McVittie <smcv@debian.org> writes:
On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
Luca Boccassi <bluca@debian.org> writes:
It is correct as-is. VERSION_ID is meant to identify a release, not
updates or point releases. A release as in, Debian Bookworm, or Fedora >>> 40, or Ubuntu Noble, and so on.
Why would you not want to identify point releases? This really
surprises me.
I think the idea is that two releases have a different VERSION_ID if and only if they can both be fully up to date, but still remain
different. If we make the analogy of git, VERSION_ID labels a branch,
not a tag.
Oh, thank you, this was not at all obvious to me. If this is indeed the case, that would be a useful clarification to add to the specification.
This also explains the desire to identify testing as trixie, but not
identify unstable as trixie. If one configures a testing system to point
to trixie, then fully updating it will move it into the stable release
when the stable release comes out. However, if one points a system at unstable, that system will never become a trixie system and will always continue to point to a different release.
This is not an entirely clean analogy, since it's also possible to point a system at the testing suite directly, rather than using the code name, in which case that system will also never become trixie. So in that sense testing is simultaneously both trixie and not trixie depending on exactly
how you configure apt.
This sort of ambiguity is, I think, part of why this proposal generates so much discussion. Debian simply doesn't currently have clean semantics for testing. It exists in a sort of quantum superposition where it is
multiple things simultaneously for different people, and this proposal is trying to label it in a way that collapses that state to match the mental model of one group of people, invalidating the mental model of a different group of people.
"Luca" == Luca Boccassi <bluca@debian.org> writes:
1) The os-release specification must be adhered to, and it must be
possible to tell the difference between testing vs unstable, and each
must be correctly identified by the respective metadata
2) Testing and unstable can continue to remain indistinguishable, and
both be erroneously identified as trixie
Again you'll know better than me, but it seems to me rulings were made
in the past that were along similar lines (eg: usrmerge) - there
wasn't reviewable code there, no?
Sorry but I do not think that is an accurate representation. First of
all, the implementation of the spec is bugged, period - it's not about
being pedantic about it, it's about being completely incompatible: sid
is identified as trixie, and that is just plain wrong, and there's no
room for interpretation, no matter how one might try to bend it. You
might say that you don't _care_ that the implementation is buggy, you
might even say that it is worth, nay _good_ it to leave it buggy - but
buggy it is, if I create a sid image, it will never in a million years
be trixie, and yet it says it's trixie.
Secondly, I am not even sure what these conflicting requirements
actually are? Could you please spell them out? If trixie was
identified as trixie, and sid was identified as unstable, what
compromise would be, er, compromised, precisely? Because the only
practical objections I could find were based on the idea that
implementations would be ugly or hard to maintain or so - as already mentioned, I am happy to relieve anybody else and take that hard and
ugly maintenance burden for myself. What other actual problem would
suddenly appear? What feature or advantage do we leave behind? How are
things made worse for our users?
in the weirdest places. Here's one I am well familiar with as the git
history will show:
https://github.com/openSUSE/obs-build/blob/master/build-recipe-livebuild#L138
build live-build based images in the open build service, because of
this base-files bug. Fortunately at the time we didn't care about
that, for external reasons, so it didn't cause troubles, besides
needing to hack it.
Here's a random one, first result found searching on Github:
https://github.com/lpereira/hardinfo/blob/4c97625c5666fa5fc353e7cab322b09159e54ed4/modules/computer/os.c#L486
/* HACK: Some Debian systems doesn't include the distribuition
* name in /etc/debian_release, so add them here. */
Note how it starts with HACK, all caps? This is what we subject our
users to. This is what we are known for. What do we even gain in
exchange?
"Ah it's Debian Trix..."
$ sudo build/systemd-dissect --copy-from image.raw
/etc/apt/sources.list /tmp/sources
$ grep Suites /tmp/sources
Suites: unstable
Suites: unstable-debug
"Oh wait no, it's Debian Si..."
$ sudo build/systemd-dissect --copy-from image.raw /etc/debian_version /tmp/debian_version
$ cat /tmp/debian_version
trixie/sid
"Oh no, wait, it's... both?!"
To be pedantic, please note that /etc/os-release is a symlink, not a conffile. The real content is in /usr/lib/os-release.
I do not find using t-p-u to update the content ugly at all to be
honest, it's there to be used as a piece of infrastructure. I do not
see anything wrong with using it? What would be the actual issue? and
anyway as already mentioned, I am fine with taking the burden of such ugliness upon myself, so that nobody else has to be subjected to it.
Consider adding a new Debian binary package containing /etc/os-release
with contents suitable for unstable. This package would use the
dpkg-divert mechanism to avoid a conflict with base-files which would continue to install /etc/os-release with contents suitable for testing (even in unstable). We would mark this new package "Essential: yes",
but have no other package depend on it. We would also file a permanent rc-bug to prevent it from migrating to testing. As a result, the set of essential packages as discovered by bootstrapping tools would differ between testing and unstable and the /etc/os-release would be diverted
for unstable only. A significant downside of this approach is that all existing unstable systems would never install this package (and thus continue to be seen as testing installations) and all systems that were bootstrapped as unstable would be keep this package even if they were to
be downgraded to testing at a later time (unless the administrator
actively removes the new package).
The downsides you have mentioned are significant already, and also as
you know I very strongly dislike dpkg-diverts, but that's my problem. However, having complex maintainer script machinery in the essential
set is everyone's problem, as it can and will break, and as above, I
am sure it is best avoided. This still requires blocking the migration
of a package, so it does not seem to me it provides any advantages
over simply having an os-release binary package pinned to unstable,
with no maintainer scripts, and just the content appropriate for
unstable inside it. It still requires overruling the base-files
maintainer. What would be the difference/advantage over the other
approach?
We have a disagreement about whether the information you intend to
convey actually exists beyond the point in time where you deboostrap. If
I debootstrap unstable and look at it a week later, it more closely represents testing than unstable.
I don't think so. It is unstable, one week out of date. It's not any different than running "debootstrap bookworm" and checking back X
weeks later, after a point release is available - it will be outdated,
but still bookworm, and still one apt update; apt upgrade away from
being up to date again. Same for unstable: if it's a week old, after
you apt upgrade it, it will be on par again. It will not magically
become testing by itself. If you debootstrap unstable today and check
back again in a year, it will not be stable trixie, it will be
outdated unstable, and an apt upgrade will make it an up to date
unstable.
Thank you for referencing a practical effect. It is not clear how mkosi uses the Release field and why it is important to differentiate testing from unstable though.
It's an image builder tool - it builds images, so it needs to know
_which_ image to build and in this case, I need it to build a guest
that matches the host - do I pull from testing or unstable? Which one
is this? Ah it says trixie, so I can use the trixie repository and...
oh wait now everything is broken because it was actually sid and a
transition was not finished so I got a broken image. Try again next
week?
Because it's not just standalone images, but images based on other
images (ie, sysext: https://uapi-group.org/specifications/specs/extension_image/ ). If you
cannot identify an image, what the heck did you just build? And
against what? And what do you base this other one on? Nobody knows.
And then the hacks begin.
Yes, and that solves the "wrong information given" problem (which is
new, VERSION_CODENAME was introduced somewhat recently in base-files),
but does not solve the "cannot identify image without horrendous
hacks" problem, so the implementation is still buggy - less so, but
still buggy. The point of the spec is to uniquely identify an image,
and if you are Arch and don't do releases then of course you don't
specify the release codename (there ain't one), so the field is
optional to cater to those use cases. It's not optional to cater to
the "distribution is held together with duct tape and prayers" cases,
I'm afraid. And if you don't implement the spec to enable its purpose
of identifying vendor trees, why implement it at all?
Sorry, I do not follow - how would this impact debootstrap negatively?
It's just a package with a single file? The only part to decide is
what pulls it in and yeah that should be compatible with debootstrap
of course.
The best and easiest solution is what I shared in a previous mail: a
Besides what I provided above, is there anything else required to make
it actionable?
Sorry, but there's no other way to define this than a bug. Well, there
are many more I could mention, but then Russ would whip out the cane
;-)
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.
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.
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.
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.
Hi,
[Release Team member hat on, but I only voice my opinion as a member].
On the use of tpu:
Personally, until now I fail to see enough value of being able to
distinguish unstable and testing to give the package carrying
/etc/os-release a permanent exception via tpu.
On Debian version numbers:
I my view we only assign version numbers the moment we release. You can
see that reflected in the symlink layout of debian/dists and in the trixie/Release file.
"Luca" == Luca Boccassi <bluca@debian.org> writes:
Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie <smcv@debian.org> wrote:
>>
>> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
>> > To further clarify why the status quo with
>> VERSION_CODENAME=trixie in > sid is really bad: it used to be
>> that if you had "debian" mentioned in > os-release but no other
>> version identifying fields, you knew you were > on testing OR
>> unstable and you'd have to deploy horrendous hacks to > attempt
>> and figure out which of the two it was really.
>>
>> OK, I think this is progress:
>>
>> What is the scenario / use-case in which it becomes necessary to
>> distinguish between those two suites?
>>
>> To put that another way, what external piece of software needs to
>> change its behaviour, dependent on whether you are running
>> testing (of an unspecified datestamp) or unstable (of an
>> unspecified datestamp)?
>>
>> Or perhaps you are thinking of a scenario in which a *person*
>> needs to change their behaviour, dependent on whether they are
>> running testing or unstable?
Luca> Are the examples I provided at:
Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5
Not to me.
I read what I think is the examples you linked from both bug reports.
I didn't dig too far into the github links you provided though.
What I see from your mail is that people want to distinguish unstable
from testing and have created various hacks to do so.
What I do not see is a compelling explanation of why Debian as a project wants to encourage that distinction.
I agree that people doing a thing is evidence that it has value to those people.
But I do not think you provided an explanation of what that value is.
If it were easy to distinguish testing from unstable, why would I want
to do that?
Hi
On 03-08-2024 11:58, Luca Boccassi wrote:
On the use of tpu:
Personally, until now I fail to see enough value of being able to
distinguish unstable and testing to give the package carrying
/etc/os-release a permanent exception via tpu.
Thanks for chiming in - assuming for a moment that it is decided that
the change will be implemented, do you see any technical obstacles in
using t-p-u as proposed?
The biggest reason I know against using tpu is that it currently isn't receiving the same amount of testing (be it automatic (autopkgtest,
piuparts, in the future reproducibility) or human) as
unstable-to-testing migrations receive. For the automatic part, that's obviously a solvable problem (and already on my todo list for YEARS),
but currently not the case. It also *always* requires human intervention
by the Release Team. Another issue issue with tpu is that binNMU'ing is
more difficult (I assume that's probably not very often relevant in the current case). I recall there are more issues with tpu, but I have
forgotten them. When I find them, I'll add them.
=====
BEGIN BALLOT
The Technical Committee declines to overrule the maintainer of
base-files, or issue any advice on issues concerning /etc/os-release.
We do not think there is a clear proposal on the table for us to assess,
and we do not think it is appropriate to issue any general statements on
the issues concerning /etc/os-release.
A: Decline to overrule or issue advice
N: None of the above
END BALLOT
=====