However, when reporting bugs on openSUSE Tumbleweed, I’d be able to easily extract the version I’m using from file:///etc/os-release, in the form of a versioned CPE OS name: cpe:/o:opensuse:tumbleweed:20230214. The Fedora 40 Beta provides this in the form of cpe:/o:fedoraproject:fedora:40, but that’s very non-specific - OSTW’s dated versions correlate to when its build server compiles its packages.
How might I acquire the same information, considering that it’s lacking from Fedora’s /etc/os-release?
Tumbleweed and Fedora are versioned differently as is clear from your question.
Fedora is shown as CPE_NAME="cpe:/o:fedoraproject:fedora:39"in the os-release file but that is only part of the overall picture.
Version 39 has the release date when it was first released, then has many different package and kernel version updates throughout the 13 month cycle that it is supported. Thus a single date in that file would not have any bearing on the actual installed software versioning.
For example, F39 was released with kernel 6.5.6 and currently is running kernel 6.7.9 with 6.8.1 in testing and soon to be released. This is not the same as most LTS distros that try to maintain a single kernel version with minor security fixes for the whole time that version is supported. Other distros vary differently so comparing apples (tumbleweed) and oranges (Fedora) for versioning just does not work.
To report bugs on fedora you report the version of the OS, maybe the kernel version, and also the version of the package that the bug is reported against. Package versions are easily seen with the dnf or rpm commands and kernel version running is seen with the uname command.
@computersavvy, that’s at the least similar to OSTW, hence the request. Does Fedora’s build server dynamically release packages when each package’s new version is released, rather than in batches, then?
Packages seem to be somewhat bunched and released once a week, but overall with many different maintainers and many different products there appears to be no set schedule for releasing updates. Packages are updated, undergo testing, and when approved are released. This seems a continuous flow for the entire life cycle of fedora releases.
There is not a set schedule that I am aware of for bunching things together except for those items that contain many different pieces that are dependent upon each other such as libre-office, qemu, etc. Those are bunched and all the related pieces are released at the same time, but otherwise it is just a steady flow.
I did an update 2 days ago then there was more to update today. The user can choose to only do updates on their own schedule at a time of their choosing, but the updates in the repos do not seem bunched or batched that way.
Indeed, @computersavvy, I too could update a small set of packages each day on OSTW, but approximately every few days, many packages would be updated and the version would be increased. It was useful as a way of trying to version the OS, but indeed didn’t state much inherently except that that package selection had been updated to at least the versions in that version-bump.
Does anyone here have a better way to summarise the state of the OS’s package selection newness?
It sounds to me like you are looking for a single string that summarizes the individual versions of all the 1000+ packages of a regular Fedora Workstation or KDE. That is not how a traditional distro with a package manager works. Even if updates for a bunch of packages are added to the repository, a user can choose to install only some of them. Or there may be other reasons why some packages are not at the latest version that is offered in the repos. At the moment, some updates are not applied on my laptop because of a conflict with other packages I have installed from RPMFusion. At the same time, I am running kernel 6.10.6, installed from the updates-testing repository. How should this be represented in a single date string? Or another version string, for that matter.
The same is also true for Tumbleweed; just because /etc/os-release lists a particular date in a CPE string does not mean that the user has updated all packages to the versions available in the repositories on that date.
I think what you describe is more similar to the way that the Atomic variants of Fedora work. With these, you have a base image with an identifier, which is unique for all the packages and their versions that went into this base image. But even that cannot capture all the packages and their versions that a user may have layered on top.
I am aware of the fundamental discrepancies between installations in a non-monolithic OS (Like OSTW or Fedora Rawhide, unlike Windows 11). However, I’m merely looking for the best way to refer to the package selection of a specific version of a default installation image.
That might seem convoluted (because it is) but I’m unfortunately asked for an “OS version” almost every time I file a bug, and a lot of bug trackers don’t understand anything except monolithic OS’s versioning systems (like macOS and Windows’). Consequently, I want to provide the most useful version that I can, rather than merely “Fedora 40” because I want the poor triage owner to be able to see which packages that actually refers to.
When filing a bug it asks for the OS version, but the bug is also directed toward the package involved and it is easy to include the package version in the report.
If I am understanding your question the simplest way so show the initially installed version as well as the current version which has the problem would be to simply state a comparison of how that package worked when initially installed from the iso then state the issue with the updated version.
This is also easily seen for each individual package by using a combination of dnf list <package name> and dnf downgrade <package name>
The results would show the installed version (list) as well as the version in the fedora repo (downgrade) which would be the original version included in the release iso.
I just tested that with the pipewire package and got
pipewire.x86_64 1.0.7-2.fc40 @updates
and
pipewire x86_64 1.0.4-2.fc40 fedora 122 k
@computersavvy, you’re thinking of RedHat’s Bugzilla instance, but you’ve merely assumed that I’m referring to that. I usually find such a field in GitHub, Gitea, and GitLab issue presets.
Thank you. That is useful when the package is in Fedora’s repositories. However, in those situations, I usually at least initially go through RedHat’s Bugzilla instance anyway (although I’ll use your recommendation there the next time I do so).
Instead, this conundrum of mine usually applies to issues against Flatpak, Snap, AppImage, Steam-distributed, and unpackaged applications, especially cross-OS software. Microsoft’s repositories are a decent example of this - unless you can provide the triage owner with the most reproducible information possible, they usually consider your OS to be modified to the extent that they close the bug unless it can be reproduced on a VM. That’s sometimes correct, other times not. The chances of them considering the report unactionable are reduced when I can provide specific versions for everything, though.
I don’t experience this issue when using OSTW, because it provides versions for its package updates which 3rd-party developers appear to like.
Even Windows 11 is not monolithic like that. At any moment, there can be any number of updates installed; you can check out the list under “Settings > Windows Update > View update history”.
A base Windows build and the installed updates make up a particular system (and then, of course, all the other programs you download from random websites). And I am also not aware of an identifier on Windows that would summarize the base build and the installed KB… updates.
In any case, if you need the full list of all installed packages for a bug report, you can always generate it and attach it, in case the developers need it:
@l-c-g, a small amount of KBs shall be installed for all installations of certain builds. Of course, most other KBs are hardware-specific, and thus outside the purview of this. Remember, I’m merely trying to match the default package selection, not any modifications performed automatically or manually subsequent to installation.
You’re kind, but again, I am aware of how best to provide this information. However, that doesn’t work when I only have a single line that I can either fill with the CPE ID or a URI to the relevant build - I’m trying to best provide useful information within the limits that I’m bound to.
Then I must have misunderstood, I thought that capturing the exact state of the system at time X is what you are after. If you don’t need anything that happened after the installation, then “Fedora 40 Workstation/KDE/Server/etc.” (or 41, 42, …) is your answer.
I am sorry I was unable to show you something new.
I still think that you are trying to solve a problem that does not exist. I doubt there really are projects that close a bug report just because they consider “Fedora 40” not accurate enough. And even if there were, something like the CPE string from OpenSuSE Tumbleweed is giving an illusion of accuracy that simply does not exist. Because as I pointed out earlier, even the CPE string really does not tell you which packages have been updated and which have not. If such a level of accuracy is needed, you can always give the maintainer the full list of packages, simply attach it to the bug report. And as for your argument that you cannot put this in a single version field: while this is certainly correct, I have yet to see a halfway decent bugtracker that does not accept attachments.
@l-c-g, ideally, but what I really need is the closest approximation in a single line. If this could be a hash or URI, it would be a damn lot easier in aforementioned situations. Otherwise, I definitely provide a package+version list when I can - it’s a very good idea of yours.
Indeed, but there are some God-awful trackers out there that I’ve had the pleasure of using. This hasn’t in practice applied to those, though, since the triage owners generally expect bad reports from users of a bad tracker.