Yes, please.
My reasoning:
There are many reasons why .spec files have to diverge between branches, including for:
- mass rebuilds after branching a new fedora release,
- rebuilds for .soname changes (usually in rawhide),
- bug fixes / patches specific to a certain branch,
- changed Packaging Guidelines (for example, due to obsolete scriptlets).
All this inevitably leads to diverging %changelogs, Release: tag values - and to a lot of conditionals, if the .spec files need to be kept "compatible" between branches for some reason.
In my opinion, the benefit of being able to "merge" (in quotes, because merging changelogs doesn't work) newer branches into old ones is dwarfed by the additional burden of maintaining and constantly updating all conditionals (which leads to bugs). As Igor mentioned, all rich deps, most virtual provides, most scriptlets, etc. have to be wrapped.
As a result, some packagers don't seem to care (or don't have the time) to update their packages for changed Guidelines (because adding and maintaining all those conditionals correctly is hard, I guess). This leads to .spec files for rawhide packages which don't comply with the current Packaging Guidelines - or to bugs or undesired behaviour changes. Additionally, provenpackagers and co-maintainers have to deal with the conditionals mess anyway if they want to (or have to) step in to fix occurring issues.
I find it hard to track changes to the Packaging Guidelines, and when those changes are made, they sometimes only apply to certain branches (or only to rawhide), and it's no longer clear which Guidelines apply to other branches.
It would be really useful to have a wiki page outlining where the Guidelines for stable branches are different to the most recent version of the Packaging Guidelines (if such a page already exists, please ignore this and point me to it).
With this information as an authoritative source (current Guidelines for rawhide branch, and exceptions/adaptations for other branches and EPEL), we could start pointing out where .spec files (regardless of the branch) don't comply (anymore) with the applicable "version" of the Guidelines, and start to remove conditionals where they can be removed, and to report / fix issues - with little to no room for differences in "taste" or "interpretation".
Conditionals for current fedora releases aside, checks for releases that have reached EOL should be cleaned up as soon as possible anyway (I still find .spec files referencing fedora 21 or earlier sometimes) ...
TL;DR:
- We need an authoritative source that tells us packagers which Guidelines apply to which branch (or what has to be done differently - or can be done better - in, for example, f26 when compared to the current Packaging Guidelines).
- With this information, we can start cleaning up unneccessary or outdated conditionals in .spec files, and can probably remove all conditionals (depending on %{?fedora}) altogether - since IMO the maintenance burden and error-prone-ness of "compatibility" between branches is way greater than the benefit of being able to "merge" (caveat changelogs, Release tags, other changes) from newer to older releases.
- This will, over time (as changes to rawhide trickle down into what will become fedora 28/29 and fedora 29/30), lead to much simpler, less error-prone, and more easily maintainable .spec files (which benefits maintainers, co-maintainers, provenpackagers, and users).
- Independently, I think conditionals for releases older than N-2 (currently: 24 and earlier) should be removed either way, and checks for fedora < N-1 should be removed after the corresponding release reaches EOL.
Fabio