Fc37.1 - what is .1 here?

[abitrolly (Anatoli Babenia)]

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?

-alexandria-0.7.9-1.fc37.1.noarch
+alexandria-0.7.9-2.fc37.noarch

https://src.fedoraproject.org/rpms/alexandria/c/592afbdb173b0ac7e83be27812574563caa8b992?branch=f37

[alys]

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:

Fedora Linux 37 update - Fedora Magazine

[vekruse (Villy Kruse)]

@abitrolly

I see that is was added by mass rebuild. Why? What for? Why it didn’t increment package version instead?

Nothing, other than making the full name different from the previous.

[abitrolly (Anatoli Babenia)]

@vekruse

Nothing, other than making the full name different from the previous.

But that’s what the package release increment is for. Why mess with the arch and platform suffixes? Neither of these is changed/updated.

[augenauf (Flo)]

According to Versioning Guidelines :: Fedora Docs

1.0.0	pkg-1.0.0-1%{?dist}	A release
	pkg-1.0.0-2%{?dist}	A rebuild from the same sources

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:

<pkgrel>[.<extraver>][.<snapinfo>]%{?dist}[.<minorbump>]

If you need a solid answer, contact the Release engineering team (releng) on their mailing list.

[abitrolly (Anatoli Babenia)]

This minorbump is listed in a section about deprecated versioning scheme.

Versioning Guidelines

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.

[ankursinha]

From what I know releng automates the specbumps, using rpmdev-bumpspec from the looks of it:

https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_161

In this particular spec, the release field looks a little complex—it uses another macro in there and so on:

https://src.fedoraproject.org/rpms/alexandria/blob/592afbdb173b0ac7e83be27812574563caa8b992/f/alexandria.spec#_17

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:

https://pagure.io/rpmdevtools/blob/main/f/rpmdev-bumpspec

[abitrolly (Anatoli Babenia)]

From this commit it looks like the macro is used for manual bumping of release field in package id.

https://src.fedoraproject.org/rpms/alexandria/c/52e3400d083ddc8189933655f1298d5103bda928#_5

So what is the recommended to increase package release number without such macros?

[ankursinha]

Not sure what you mean. Usually, one just increases the release field manually:

Release:    1%{?dist}
Release:    2%{?dist}

and so on.

[abitrolly (Anatoli Babenia)]

Thanks. Now I see the problem. Because package Release: tag and Dist Tag are not separated, people who want clarity, maintain their own macros.

- %define        fedorarel    4
+ %define        fedorarel    5
 %define        rel        %{?ifpre:0.}%{fedorarel}%{?minorver:.%minorver}
 
 Name:        alexandria
 Version:    %{majorver}
 Release:    %{rel}%{?dist} 

I guess that %{rel} macro is invalid, because it seems to append a 0. prefix to Release: field if some pre condition is set, and Release: field can only contain integers starting from 1. However, I can not say for sure, because I could not find formal reference for spec fields. Issue #1231: [master] Doc issue in file guidelines/modules/ROOT/pages/Versioning.adoc - packaging-committee - Pagure.io

Why not just have optional Dist: field defaulting to %{?dist} there?

[ankursinha]

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.

Versioning Guidelines

@abitrolly

Why not just have optional Dist: field defaulting to %{?dist} there?

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.

---

Take a look at this:

https://rpm-software-management.github.io/rpm/manual/tags.html

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:

$ cat /usr/lib/rpm/macros.d/macros.dist 
# dist macros.

%__bootstrap         ~bootstrap
%fedora              37
%fc37                1
%dist                %{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,9999 do print("%{?distprefix" .. i .."}") end}}.fc%{fedora}%{?with_bootstrap:~bootstrap}
%dist_vendor         Fedora
%dist_name           Fedora Linux
%dist_home_url       https://fedoraproject.org/
%dist_bug_report_url https://bugzilla.redhat.com/
%dist_debuginfod_url https://debuginfod.fedoraproject.org/

One can check the value of a macro using rpm -E:

$ rpm -E "%dist"
.fc37

This is all just rpm related bits, they’re not specific to Fedora. For our builds, we only set the macros for each release etc.

[abitrolly (Anatoli Babenia)]

@ankursinha

It isn’t invalid. If there’s a prerelease version being packaged, the release field should start with 0.x.

This prerelease topic is described in the section about deprecated versioning scheme. My understanding that if something is deprecated, it should not be recommended.

@ankursinha

Take a look at this:

rpm.org - RPM Tags

Tags can also be defined in rpm macro definition files.

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.

@ankursinha

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.

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?

[ankursinha]

@abitrolly

This prerelease topic is described in the section about deprecated versioning scheme. My understanding that if something is deprecated, it should not be recommended.

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.

@abitrolly

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.

They’re not supposed to. They sort of run into this when learning how to package an RPM:

Packaging Tutorial: GNU Hello

links to the [RPM reference manual]( RPM Reference Manual, which provides information on RPM tags and so on.

@abitrolly

So I expect the spec to treat it separately for simplicity. Defining a default value for it should be enough.

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.

@abitrolly

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?

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.

[abitrolly (Anatoli Babenia)]

@ankursinha

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.