SPECfiles - conditionals with EOLed Fedora releases - any value keeping them?

Project Discussion
,
1

Hello,
While playing around with Sourcegraph, that indexed all Fedora package repositories, I was able to craft a query listing all ‘%if’ conditionals referencing Fedora releases that reached EOL.

https://sourcegraph.com/search?if_conditionals_referencing_EOL_fedora_releases

I don’t believe such conditions have any value and I think we can remove them right away.
I think the removal shouldn’t affect nor Fedora nor derived operating systems.

If removed, they will be preserved in the git history anyway, for anyone seeking historical code.

In some cases the conditionals holds patched that could be removed with them:
https://sourcegraph.com/search?if_conditionals_with_EOL_Fedora_releases_holding_patches

–

Do you agree it would be safe to remove such conditionals and the code they hold ?
Do you agree that removing obsoleted code such as this bring value to the package codebase ?

Would you see a value in e.g. some kind of a robot reminding maintainers of such obsolete code?
(e.g. new RPMinspect or ZUUL CI check)

1 Like
2

I think, EOL Fedora versions may be relevant when you are creating a EPEL branch of a package for currently supported version of RHEL/CentOS.

For example when creating the EPEL 9 package now, you would probably still look into f34 and f35 conditionals in the spec file?

3

I assume that EPEL honor “0%{?rhel} >= 8” macros, instead of “%{?fedora}>=34” ones.

Which would mean that the “%{?fedora}” macros are not useful for EPEL, only for package maintainers converting a Fedora package to EPEL one.

I see a value in having synced SPECfiles between Fedora releases or even between Fedora, CentOS / EPEL and RHEL (e.g. by having “0%{?rhel} >= 7” statements in the Fedora SPECfile).

I don’t see the value when this is not used. Either when maintainer does not want to keep the SPECfile in sync, or they just differ too much to use conditionals, or simply when the package only exists in Fedora.

The (possibly) removed obsolete conditionals would still exists in the git history.
And since Fedora is expected to be fast pacing OS, getting the latest updates all the time, I’d argue that EPEL maintainer should alwayys check the git history diff between Rawhide and the Fedora release on which the targeted RHEL release was born.

–

TL;DR: I think the conditionals with EOLed releases should be removed, and only re-introduced as “0%{?rhel} >= X” macros when needed.

However the people who actually make new EPEL packages should tell us if the current state is helpful to them in any way.