Clarify distribution conditionals in spec files

fweimer commented

2026-06-19 14:30:34 +00:00

Member

The Packaging Guidelines currently say this, under Spec Legibility:

To help facilitate legibility, only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. Use of macros and conditionals for other distributions, including Fedora derivatives, is not permitted in spec files of packages in the main Fedora repositories unless those macros and conditionals are also present in Fedora.

I would like to get this changed to explicitly permit %fedora, %rhel, %centos, %epel, and their variants such as %{?fedora}0. And I believe %hummingbird should be added to this list, too, now that Hummingbird images are part of the Fedora family.

The Packaging Guidelines currently say this, under [Spec Legibility](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility): > To help facilitate legibility, only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. Use of macros and conditionals for other distributions, including Fedora derivatives, is not permitted in spec files of packages in the main Fedora repositories unless those macros and conditionals are also present in Fedora. I would like to get this changed to explicitly permit `%fedora`, `%rhel`, `%centos`, `%epel`, and their variants such as `%{?fedora}0`. And I believe `%hummingbird` should be added to this list, too, now that Hummingbird images are part of the Fedora family.

churchyard commented

2026-06-19 15:26:55 +00:00

Owner

+1 to explicitly permit %fedora, %rhel, %centos, %epel which reflects the reality.

-1 to allowing %hummingbird at this moment. I think this requires more discussion, and I don't want to block the previous point on that.

+1 to explicitly permit %fedora, %rhel, %centos, %epel which reflects the reality. -1 to allowing %hummingbird at this moment. I think this requires more discussion, and I don't want to block the previous point on that.

gotmax23 commented

2026-06-20 22:12:44 +00:00

Owner

%rhel is meant to be used in conditionals for Fedora EPEL and ELN, so I think this is already allowed under the current Guidelines. %rhel and %epel are defined when building packages for Fedora EPEL and ELN (Extras), so "those macros and conditionals are also present in Fedora" is a true statement. If we consider Hummingbird part of Fedora, I think %hummingbird would also be allowed.

Beyond that, I am not a huge fan of changing this to list or special case specific downstream distributions that are not part of the Fedora Project. That opens up a whole 'nother can of worms. I would rather consider allowing conditionals for any derivative of Fedora provided that the conditional does not add significant complexity or significantly impact legibility.

`%rhel` is meant to be used in conditionals for Fedora EPEL and ELN, so I think this is already allowed under the current Guidelines. `%rhel` and `%epel` are defined when building packages for Fedora EPEL and ELN (Extras), so "those macros and conditionals are also present in Fedora" is a true statement. If we consider Hummingbird part of Fedora, I think `%hummingbird` would also be allowed. Beyond that, I am not a huge fan of changing this to list or special case specific downstream distributions that are not part of the Fedora Project. That opens up a whole 'nother can of worms. I would rather consider allowing conditionals for any derivative of Fedora provided that the conditional does not add significant complexity or significantly impact legibility.

ngompa commented

2026-06-21 03:38:05 +00:00

Owner

I think if we do this, we should just drop the rule entirely and replace it with guidance on how we want distro conditionals to be used.

berrange commented

2026-06-22 08:25:03 +00:00

Member

@ngompa wrote in #1546 (comment):

I think if we do this, we should just drop the rule entirely and replace it with guidance on how we want distro conditionals to be used.

IMHO, the legibility win comes from following the Fedora packaging guidelines.

If the use of other distro name conditionals is a mechanism to perform content selection that is not going to significantly harm legibility as it is mostly just boolean choices.

If the use of other distro name conditionals is a mechanism to switch between two different sets of packaging guidelines that is where the complexity and legibility concerns can start to arise depending on what the alternate guidelines are.

With %rhel/%centos/%epel macros, we have two typical uses.

For content selection, since RHEL often wants to turn off features Fedora would otherwise ship
For compatibility with older Fedora packaging guidelines, since RHEL can be following guidelines from several years ago which Fedora has either partially or fully migrated away from.

I would be inclined to allow distro conditionals in those two cases, but explicitly exclude the scenario where a conditional is used to select compat with guidelines that did not originate in Fedora (neither current, nor historical). That would exclude sharing specs with other RPM based distros outside the Fedora family tree, or other custom downstream distro guidelines intended to replace/override guidelines already defined by Fedora.

@ngompa wrote in https://forge.fedoraproject.org/packaging/guidelines/issues/1546#issuecomment-823638: > I think if we do this, we should just drop the rule entirely and replace it with guidance on how we want distro conditionals to be used. IMHO, the legibility win comes from following the Fedora packaging guidelines. If the use of other distro name conditionals is a mechanism to perform content selection that is not going to significantly harm legibility as it is mostly just boolean choices. If the use of other distro name conditionals is a mechanism to switch between two different sets of packaging guidelines that is where the complexity and legibility concerns can start to arise depending on what the alternate guidelines are. With %rhel/%centos/%epel macros, we have two typical uses. * For content selection, since RHEL often wants to turn off features Fedora would otherwise ship * For compatibility with older Fedora packaging guidelines, since RHEL can be following guidelines from several years ago which Fedora has either partially or fully migrated away from. I would be inclined to allow distro conditionals in those two cases, but explicitly exclude the scenario where a conditional is used to select compat with guidelines that did not originate in Fedora (neither current, nor historical). That would exclude sharing specs with other RPM based distros outside the Fedora family tree, or other custom downstream distro guidelines intended to replace/override guidelines already defined by Fedora.

decathorpe commented

2026-06-24 07:53:01 +00:00

Owner

With %rhel/%centos/%epel macros, we have two typical uses.

The same two reasons apply to Amazon Linux and Azure Linux too. Do we want to allow conditionals for these two too? And where does it "end"? ^_^

Maybe rather than having a list of "allowed" macros, document how distribution conditionals should be used?

> With %rhel/%centos/%epel macros, we have two typical uses. The same two reasons apply to Amazon Linux and Azure Linux too. Do we want to allow conditionals for these two too? And where does it "end"? ^_^ Maybe rather than having a list of "allowed" macros, document how distribution conditionals should be used?

carlwgeorge commented

2026-06-24 22:48:40 +00:00

Owner

Maybe rather than having a list of "allowed" macros, document how distribution conditionals should be used?

💯

I've had several discussions with AWS folks (cc: @fredlefebvre) about this specifically. Many of their downstream modifications are just basic bcond changes based on the amzn macro being defined. Often times these align with rhel conditions, so my guidance has been to rework the conditional so that both RHEL and Amazon Linux match the %else condition. Describing this and other best practices in documentation has been on my to-do list for a while, but if someone else has time to get it started before me I'm happy to help contribute to it.

I agree with @decathorpe's point that we should avoid just expanding the list of allowed macros. Distro-specific macros easily get out of hand and reduce legibility. An alternative that Fedora downstreams could consider is using bcond overrides to globally disable generically-named bcond such as docs.

https://rpm.org/docs/latest/manual/conditionalbuilds.html#overriding-defaults

> Maybe rather than having a list of "allowed" macros, document how distribution conditionals should be used? 💯 I've had several discussions with AWS folks (cc: @fredlefebvre) about this specifically. Many of their downstream modifications are just basic bcond changes based on the `amzn` macro being defined. Often times these align with `rhel` conditions, so my guidance has been to rework the conditional so that both RHEL and Amazon Linux match the `%else` condition. Describing this and other best practices in documentation has been on my to-do list for a while, but if someone else has time to get it started before me I'm happy to help contribute to it. I agree with @decathorpe's point that we should avoid just expanding the list of allowed macros. Distro-specific macros easily get out of hand and reduce legibility. An alternative that Fedora downstreams could consider is using bcond overrides to globally disable generically-named bcond such as `docs`. https://rpm.org/docs/latest/manual/conditionalbuilds.html#overriding-defaults

yselkowitz commented

2026-06-24 23:13:26 +00:00

Member

While the idea of global bcond overrides as a fix-all to distribution differences comes up from time to time, I am not convinced that it is a viable solution due to lack of consistency between packages and use cases.

👍 1

carlwgeorge commented

2026-06-25 03:40:51 +00:00

Owner

It won't cover 100% of cases, but it does cover quite a bit, and with a little bit of focus on consistency (e.g. standardize on %bcond tests over %bcond check), it will cover even more. We don't need to hit 100% anyways, because downstreams will always maintain their own changes, and all we can do is try to facilitate minimizing those changes if possible with bconds and bcond overrides.

It won't cover 100% of cases, but it does cover quite a bit, and with a little bit of focus on consistency (e.g. standardize on `%bcond tests` over `%bcond check`), it will cover even more. We don't need to hit 100% anyways, because downstreams will always maintain their own changes, and all we can do is try to facilitate minimizing those changes if possible with bconds and bcond overrides.

ngompa commented

2026-06-25 04:34:04 +00:00

Owner

Build conditions don't intrinsically make legibility better, and can sometimes make it worse, since that is often due to structural differences. We see this a lot in RPM Fusion and some Fedora packages that originate from there.

I'm not swayed by @berrange's argument about legibility for distro conditionals either because they're already starting to get bad between Fedora and RHEL.

It's particularly awful with toolchain packages and the kernel, both of which somewhat treat Fedora as a special case rather than the default case.

Build conditions don't intrinsically make legibility better, and can sometimes make it worse, since that is often due to structural differences. We see this a lot in RPM Fusion and some Fedora packages that originate from there. I'm not swayed by @berrange's argument about legibility for distro conditionals either because they're already starting to get bad between Fedora and RHEL. It's particularly awful with toolchain packages and the kernel, both of which somewhat treat Fedora as a special case rather than the default case.

berrange commented

2026-06-25 11:11:17 +00:00

Member

@ngompa wrote in #1546 (comment):

I'm not swayed by @berrange's argument about legibility for distro conditionals either because they're already starting to get bad between Fedora and RHEL.

It's particularly awful with toolchain packages and the kernel, both of which somewhat treat Fedora as a special case rather than the default case.

There are certainly cases where it ceases to be sensible to have a shared spec between Fedora and RHEL. In QEMU we always took the view that the RHEL spec is too different to want to try to merge with Fedora.

I've not looked at toolchain packages, but IMHO the kernel in particular is quite an extreme example for RPM packaging in general.

We have over 1700 packages using %rhel dist tags and I expect the overwhelming majority are quite reasonable and bring benefit to the maintainers workload through sharing specs. We shouldn't make a policy based on targetting a handful of bad examples, that would negatively impact 1000's of acceptable examples.

We'll never get perfection no matter how strictly we define the rules. We need to aim to maximise the positive usage, but accept there will always be a small number of undesirable examples. Work to improve the undesirable examples through proposing spec changes, rather than trying to litigate it through rules.

I do think that the default case should be Fedora, with downstream being the special case, but that's quite a nebulous concept to express.

@ngompa wrote in https://forge.fedoraproject.org/packaging/guidelines/issues/1546#issuecomment-866888: > I'm not swayed by @berrange's argument about legibility for distro conditionals either because they're already starting to get bad between Fedora and RHEL. > > It's particularly awful with toolchain packages and the kernel, both of which somewhat treat Fedora as a special case rather than the default case. There are certainly cases where it ceases to be sensible to have a shared spec between Fedora and RHEL. In QEMU we always took the view that the RHEL spec is too different to want to try to merge with Fedora. I've not looked at toolchain packages, but IMHO the kernel in particular is quite an extreme example for RPM packaging in general. We have over 1700 packages using %rhel dist tags and I expect the overwhelming majority are quite reasonable and bring benefit to the maintainers workload through sharing specs. We shouldn't make a policy based on targetting a handful of bad examples, that would negatively impact 1000's of acceptable examples. We'll never get perfection no matter how strictly we define the rules. We need to aim to maximise the positive usage, but accept there will always be a small number of undesirable examples. Work to improve the undesirable examples through proposing spec changes, rather than trying to litigate it through rules. I do think that the default case should be Fedora, with downstream being the special case, but that's quite a nebulous concept to express.

zbyszek commented

2026-06-29 19:11:00 +00:00

Member

@gotmax23 wrote in #1546 (comment):

I would rather consider allowing conditionals for any derivative of Fedora provided that the conditional does not add significant complexity or significantly impact legibility.

Yes. But complexity is in the eye of the beholder. I'd just delegate to packagers:

"Spec files MAY contain conditionals for Fedora releases and any derivatives. Conditionals that create significant complexity or negatively impact legibility are discouraged, and packagers SHOULD consider using separate branches in that case."

@gotmax23 wrote in https://forge.fedoraproject.org/packaging/guidelines/issues/1546#issuecomment-823298: > I would rather consider allowing conditionals for any derivative of Fedora provided that the conditional does not add significant complexity or significantly impact legibility. Yes. But complexity is in the eye of the beholder. I'd just delegate to packagers: "Spec files MAY contain conditionals for Fedora releases and any derivatives. Conditionals that create significant complexity or negatively impact legibility are discouraged, and packagers SHOULD consider using separate branches in that case."

gotmax23 commented

2026-06-29 19:42:52 +00:00

Owner

That proposal sounds reasonable, but I'd say "packagers SHOULD use separate branches" instead of "SHOULD consider using separate branches" to make the statement stronger/more concise.

I believe @ngompa was also working on a more comprehensive set of Guidelines about distro packaging conditionals.

That proposal sounds reasonable, but I'd say "packagers SHOULD use separate branches" instead of "SHOULD consider using separate branches" to make the statement stronger/more concise. I believe @ngompa was also working on a more comprehensive set of Guidelines about distro packaging conditionals.

👍 1

decathorpe commented

2026-07-11 23:22:55 +00:00

Owner

If we decide to add guidelines specific to "how and when to use conditionals", I think it might be interesting to distinguish between what can / cannot be the content of a conditional, and what can / cannot be the actual controlling condition: Something like "if rhel: bcond docs 0" is usually fine, something like "if today == wednesday: Version: 42" is probably not. :)

If we decide to add guidelines specific to "how and when to use conditionals", I think it might be interesting to distinguish between what can / cannot be the *content* of a conditional, and what can / cannot be the actual controlling *condition*: Something like "if rhel: bcond docs 0" is usually fine, something like "if today == wednesday: Version: 42" is probably not. :)

ngompa commented

2026-07-11 23:28:11 +00:00

Owner

Yes, that's a good idea, I'll incorporate that into my draft.

❤️ 1

ngompa self-assigned this

2026-07-11 23:28:15 +00:00

zbyszek commented

2026-07-12 07:20:02 +00:00

Member

Something like "if rhel: bcond docs 0" is usually fine, something like "if today == wednesday: Version: 42" is probably not. :)

I'd say the opposite ;)

The first should be spelled %bcond docs %{undefined rhel} or equivalent.
The second is useful, see https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_78.

> Something like "if rhel: bcond docs 0" is usually fine, something like "if today == wednesday: Version: 42" is probably not. :) I'd say the opposite ;) The first should be spelled `%bcond docs %{undefined rhel}` or equivalent. The second is useful, see https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_78.

👎 1

zbyszek commented

2026-07-21 10:17:38 +00:00

Member

@ngompa you mentioned a draft. Is it available somewhere?

Rows
Columns

Clarify distribution conditionals in spec files #1546