According to https://fedorahosted.org/fpc/ticket/581#comment:6, the spec legibility requirement in the current packaging guidelines has been determined to disallow the use of cross-distro SRPMs to build mainline Fedora packages: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility
The stated rationale for this policy is to lower barriers to entry for new Fedora packagers: cross-distro SPEC files naturally include more conditional logic and RPM macros, and hence can be harder for new users to read. However, this comes at the cost of raising barriers to entry for potential Fedora packagers that care about more distro targets than just Fedora. The specific contributor base that filed #581 were the SCL maintainers for Fedora/CentOS, but a similar argument also applies for EPEL, CentOS, OpenSUSE, Mageia, Scientific Linux, Amazon Linux, Photon, ROSA Linux, Facebook's FBOSS, and more.
At the moment, package maintainers for these other distros are effectively excluded from contributing their packages to Fedora, as doing so would necessarily require maintaining a completely independent SRPM, rather than crafting a combined SRPM that met the packaging policies of both distros. Delegating the trade-off between spec file legibility and cross-distro compatibility to individual package maintainers could lower barriers to entry for packagers already building RPMs for other distros, while improvements to automated spec file generation tools like pyp2rpm can help to lower barriers to entry for new packagers.
Concrete proposal is that the following paragraph be added to the spec legibility section of the guidelines:
To help facilitate cross-distro collaboration, macros and conditionals enabling support for multiple distros in a single spec file are allowed to be used in Fedora Packages. Package maintainers are responsible for ensuring that the spec file remains legible even when supporting multiple distros.
The current section specific to Software Collection Macros (https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros) would be removed entirely, with SCLs considered a cross-distro macro for RHEL/CentOS from Fedora's perspective (even though SCLs can be built to target Fedora).
Which package maintainers? Remember that packages don't belong to individuals.
We enforce American English in specfiles. I have no idea why we'd do that and say "but feel free to pile in a bunch of stuff not even related to building the package in Fedora".
Being able to read and write in English is an inherent barrier to participation in the Fedora community - if you can't do that, then you're not going to be able to participate in any design or policy discussions. As such, a requirement to use English in spec files adds no new barriers to entry.
By contrast, telling people that "only pure Fedora contributors are welcome, if you also care about downstreams or other RPM based distros, we don't want you here" encourages exactly the scenario that is happening with SCLs: the FPC is asking contributors to a downstream distro to do additional work that doesn't benefit them or their users that is also of at best dubious benefit to Fedora users, so the natural reaction is "No, I'll find a less time consuming way to solve my problem" (regardless of whether those downstream contributors work for Red Hat or not).
That other way generally means skipping contributing packages to mainline Fedora, and moving them out into alternative channels like COPR instead. That's FPC's decision to make, and if that's the direction you'd prefer to go, then I'd suggest some explicit wording like the following in the packaging guidelines (while still dropping the SCL specific exclusion):
To help facilitate legibility, only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. Macros and conditionals for other distros, including Fedora derivatives, are not permitted in the main Fedora repositories (unless those macros and conditionals are also present in Fedora). Packagers wishing to use cross-distro spec files to produce Fedora RPMs remain free to use COPR rather than the main Fedora repositories.
This would help make it clear that the FPC's decision on #581 was not motivated by personal animosity towards the SCL developers (because the IRC meeting logs sure as hell read that way, as does the fact that the SCL exclusion is documented in the guidelines, while the exclusion of cross-distro spec files is an unwritten rule).
In the multi-ring model of Fedora, I think that contributing packages that run on Fedora through COPR does deserve more calling out. I'm not an FPC member but the proposal in https://fedorahosted.org/fpc/ticket/582#comment:6 seems like a good change. It spells out the corollary to the existing legibility guidelines that we've had for years but new packagers may not be aware of and it promotes the use of COPR to build and host packages for Fedora.
I'm not 100% opposed to the original desire, but it would need to be more specific. Which distro. macros do they want to use etc. The optimistic part of me always assumed we could live in a wonderful future where specfiles are 99% shared with SuSE/CentOS/Mageia/whatever, and they look smaller and cleaner than they do today.
So, if you have examples/desires of sharing you'd like to see happen ... feel free to add them here (guessing you won't be around at 3am your time tomorrow).
The more realistic part of me though knows that everyone puts stuff in different places, implements core features in different ways etc. etc. and passing something that general will just be a non-obvious way of letting everyone do whatever they feel like.
I don't mind #6, although it removes some grey for anyone.
After thinking about this for a bit longer, I'm thinking the revised proposal in https://fedorahosted.org/fpc/ticket/582#comment:6 makes the most sense , and the rationale for that relates to the difference between being in Fedora, and being available on Fedora.
The idea behind allowing other build system macros is to lower the barriers to making software already packaged as RPMs also available to Fedora users. Such software is likely to be non-compliant with Fedora's policies in a variety of ways (not just legibility), so putting it in COPR makes a lot of sense anyway.
Mainline packages, on the other hand, are intended to actually be part of the distro itself, and so the additional hurdle of being willing to provide a Fedora specific spec file helps clarify whether a packager's objective is for the package to be in Fedora, or simply more readily available to Fedora users.
I did just notice something with the specific wording I suggested though: since the SCL macros are provided by scl-utils-build, and that package is available in Fedora, approving that wording and removing the section currently prohibiting SCL macros would have the effect of reversing the recent decision in #581.
If the SCL macro section is kept, then this change to the legibility section would help explain why it's there - the SCL macros are made available for use in COPR packages, downstream packages, and custom user packages, but not mainline Fedora packages.
If the proposal from https://fedorahosted.org/fpc/ticket/582#comment:6 is acceptable (although this is going exactly against the original proposal :), then why not going one step further in a direction: ".spec shoud not be conditionalized to support any older/newer releases of Fedora/EPEL". This would remove plenty of spaghetti conditions, make the spec cleaner and Fedora more flexible/agile.
IOW currently, it is very hard to update the .spec files to be up-to-date once some guideline is changed. This would allow easier automation.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-12-10/fpc.2015-12-10-17.00.txt):
Regarding vondruch's comment above, from a standpoint of cleanliness of specfiles, I love the idea but I really doubt it would go over well. Maybe if we had
What I would really like is a concerted effort to eliminate the need for ifdefs as much as possible. That's what we were aiming for with those new python macros. We have epel-rpm-macros which can handle some of it. I spent a few minutes to get %license into EPEL6 and it appears to work, so I can do the same for EPEL5 and then that's one conditional that can be dropped.
I'm sure there are others we can do as well, but due to ancient RPM versions we'll never be able to get them all. And more will be coming all the time. File triggers will be a pretty big source of them, though I have an idea of how to at least make it a little simpler. This isn't really the correct ticket for that, though.
Text was added to the section on spec legibility indicating that non Fedora/EPEL macros should not be used in Fedora specfiles.
Metadata Update from @james:
- Issue assigned to tibbs
to comment on this ticket.