We’re currently working on an openQA test for release and edition self-identification. As part of this, we noticed the contents of /etc/os-release on Rawhide Silverblue installs seems odd. Specifically, these lines:
Those do not match at all with the general form of those values used in all other Fedoras. They also do not match the values in the fedora-release-silverblue package, which is what I expected to see in an installed Silverblue. The file in that package has these values:
does anyone know where the file that actually shows up in installed Silverblue is coming from, and why it has these values? None of the other fedora-release subpackages has these values either, so I’m not sure where this file is coming from. Thanks!
Never mind, I found it. It’s a “feature” of rpm-ostree called mutate-os-release. I might argue about whether this mutation is necessary or desirable (and if so, if the value that’s being substituted into place is a good one) but at least I know what’s going on…
Hmm, one other thing to note here - it seems Silverblue is pulling in fedora-release-workstation not fedora-release-silverblue. That’s why the values have “(Workstation Edition)” and not “(Silverblue)”. Is this known / intended?
Traceroute (which is only 110KB) is often used by ISPs though to help their customers diagnose connection issues. Online games tend to ask users to use it too.
I understand telnet not being shipped by default, not even Windows ships with it.
Edit: I think MTR is in the default deployment though, so maybe traceroute isn’t needed.
If I am not mistaken, and silverblue isn’t too different from everything else
Fedora, netcat is in the default install. If this is the case, you’ve got a
telnet-compatible program there (that can do much more).
The main danger that comes to mind with this is that the release packages aren’t just branding; they also define presets. And indeed, the silverblue release package isn’t installing the workstation presets. Will look at a patch for this.
Those do not match at all with the general form of those values used in all other Fedoras.
Other Fedoras don’t have version numbers besides the major; it’s a set of independently versioned packages without any higher level coordination. Now that said I’d have expected you to observe the version number here is the same as the Pungi one. But the Pungi versioning isn’t really plumbed through into anything (lib)dnf understands so people aren’t used to seeing them.
Image systems like ostree allow you to speak about a precise version number which succinctly describes the state of the system (as long as package layering isn’t involved…)
A lot of discussion of related things in e.g. this issue.
Well…it’s similar, but not exactly, really. Pungi (or rather productmd, which is where all the rules for this sort of thing actually come from) doesn’t exactly have a “version number” concept.
There *is * a clearly defined concept called the ‘compose ID’. The compose ID of this compose is “Fedora-Rawhide-20190629.n.0”. There is also a clearly defined metadata property called the date: for the compose (which is a defined productmd property) the date is “20190629”. Ditto respin, which for this compose is “0”.
But what rpm-ostree puts into the os-release file is “Rawhide.20190629.n.0”. That’s not the compose ID, or the date, or the respin; it’s closest to the compose ID, but it clearly isn’t the same. Nothing else that I’m aware of uses a string quite like that, or would expect to process one that looks like that. Notably, just from looking at that string I am not confident I can predict for sure what that string would be in all conditions, because I can’t be sure how it’s being produced. Does rpm-ostree understand pungi compose types, such that for a Final candidate compose the string would be ‘31.20190901.0’ (note: no ‘.n.’), or is the ‘.n.’ just being cargo-culted into place? What’s that string going to be for post-release stable composes, which have compose IDs like “Fedora-29-updates-20190715.0” ? Is that “-updates-” going to wind up in this version string or not? It’s hard to be sure.
I do get the idea of trying to provide the most specific information possible about “what this ostree actually is”. My concern is just that this seems to have been sort of cooked up ad hoc for Silverblue and isn’t necessarily defined or documented anywhere as a value anyone would expect, and if someone looks at the values they find in any other Fedora install and expects to find something similar in Silverblue they might be surprised.
Basically I’d expect there to be consistency/predictability across Fedora editions and spins as to what you’re going to find in os-release (and similar files), and I’m not sure if right now the practices / policies are in place to ensure this…for instance, is the fedora-release maintainer aware that this modification happens in Silverblue?
It’s not Silverblue specific - the same thing has happened for Atomic Host for quite a while; more generally, anything generated by pungi that is based ostree. Although, it’s configurable at both ends (in pungi, and nothing requires one to set mutate-os-release in the manifest).
For things generated by coreos-assembler we also use this with the cosa concept of a “build ID” which like pungi encapsulates bootable disk images with ostree.
OK, let’s say “ostree specific” Point being, it’s not necessarily something that’s been considered or really noticed by the project as a whole, and I think release identification stuff like this needs to be co-ordinated across the project as a whole.
For the record, the values used for candidate composes seem to be based on the label (which is a thing only candidate composes have, not nightlies). E.g. for the Beta we got 31_Beta.1.1 as the version string. This is also odd and not in line with productmd; the actual label of the compose is Beta-1.1, not Beta.1.1, as you can see at https://kojipkgs.fedoraproject.org/compose/31/Fedora-31-20190911.0/compose/metadata/composeinfo.json .
Edit: also, why on earth does the string start (version).(date) for the nightlies, but (version)_(labelname) for the candidate composes?! Why a dot for one case but an underscore for the other? I think I need to go sit down with a warm cup of tea.
Point being, it’s not necessarily something that’s been considered or really noticed by the project as a whole, and I think release identification stuff like this needs to be co-ordinated across the project as a whole.