I am trying to analyze Fedora packages with Observable Fedora package cache / Anatoli Babenia | Observable and names like alexandria-0.7.9-1.fc37.1.noarch break os/arch split, because of extra .1. between fc37 and noarch.
I see that is was added by mass rebuild. Why? What for? Why it didn’t increment package version instead?
Before Fedora 37 was set to go live, there was an OpenSSL vulnerability that went public. The FP team decided to delay the release so they could integrate the patched version of OpenSSL and do a rebuild of the whole image:
Following this scheme, the release number could have been incremented to 2, leaving everything else as is.
In this case it was decided to use .minorbump to differentiate the package from the previous package name. Quoting:
minor release bump (<minorbump>)
Those items which are present are combined (with periods to separate them) to construct the final Release: tag. In the usual notation where square brackets indicate that an item is optional:
This minorbump is listed in a section about deprecated versioning scheme.
If it was not so hard to parse, I would probably leave this as-is, but at this point I am forced to ask in releng.
Strange the the documentation does not have a colored examples that can explain terminology and what is what in a package id like alexandria-0.7.9-1.fc37.1.noarch.
So perhaps it’s just rpmdev-bumpspec behaviour to use minorbump in this case (none of the ~300 packages that I maintain used this system—the release field was happily incremented in them). The source is here if anyone wants to take a look:
It isn’t invalid. If there’s a prerelease version being packaged, the release field should start with 0.x. Instead of doing it manually, they’re just using macros.
Not sure what you mean----the dist isn’t something we set, it’s set by the build system. So no reason to have it as an extra field. It’s automatically expanded to fcX for Fedora.
Tags can also be defined in rpm macro definition files. On Fedora, take a look at the /usr/lib/rpm/macros file and the many definition files in /usr/lib/rpm/macros.d.
The dist tag is defined there in /usr/lib/rpm/macros.d/macros.dist:
This prerelease topic is described in the section about deprecated versioning scheme. My understanding that if something is deprecated, it should not be recommended.
I don’t see how people reading versioning guide can discover this reference. It also doesn’t cover acceptable format for fields. There is info that Release: can only be number above 1 in new versioning scheme, and old versioning scheme is deprecated.
In a new-style versioning, in the “package ID” string like alexandria-0.7.9-1.fc37.noarch, I read the dist is a separate field.
NAME-VERSION-RELEASE.DIST.ARCH
So I expect the spec to treat it separately for simplicity. Defining a default value for it should be enough.
Dist: %{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,9999 do print("%{?distprefix" .. i .."}") end}}.fc%{fedora}%{?with_bootstrap:~bootstrap}
Also RPM specification above contains Distribution: filed. Why it is not used, and why the distribution info above is lumped into the package Release: tag?
Sure, you can interpret it that way, but there’s a difference between deprecating something and forbidding its use. It’s still supported, and folks with complex versioning schemes are still using it. I.e., it is not yet forbidden by the guidelines.
They’re not supposed to. They sort of run into this when learning how to package an RPM:
links to the [RPM reference manual]( RPM Reference Manual, which provides information on RPM tags and so on.
But it’s defined by the system wide macros—so there’s no need to repeat it in the spec. If it’s defined in each spec, folks may introduce errors into it which will break builds. So a system wide macro is used so that all packages on a particular Fedora release have the same dist value.
Again—there’s a difference between the complete feature set that rpm provides and the set that a distribution (Fedora or otherwise) chooses to adopt. We don’t have to adopt everything rpm provides—we adopt a subset and configure it for Fedora. Other rpm based distributions may adopt a different set.
You need to read the docs more carefully. It says:
Distribution: Distribution name.
Disttag: Distribution acronym.
So, the first would be “Fedora 37”, the second is “fc37”. They’re not the same thing. Using the dist tag in the release field ensures that packages have it in their file names. Perhaps the use of dist makes the user of the distribution tag redundant—fc37 clearly conveys “Fedora 37”.
–
You’re asking a lot of questions in the form “why this, why not this”. The short answer is that this is how the build system/pipeline was setup to deliver a sane set of builds. It works very well, as evidenced by all our Fedora releases. It’ll be a lot easier if you focused on how these things are already defined so you can use them instead of why—they’re not going to change without good reason.
I am focused on the bad experience while trying to build some Fedora package analytics as explained in the first message. I already know what a NEVRA is even if it is not described in the guide, and I didn’t expect to spend 3 additional days on parsing that. With clear spec on package IDs with parsing examples it wouldn’t take that long. And the problem is not solved yet, because my “parser” to separate arch and os is pure SQL, and it won’t work with such conditionals without sacrificing performance and becoming overly complicated. I won’t be surprised if dnf is so slow to detect updates, because of the same manual NEVRA calculations logic.