#581 Remove prohibition of SCL macros from Packaging Guidelines
Closed: Fixed None Opened 7 years ago by hhorak.

The packaging guidelines include now (https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros):

In the past, SCL macros were allowed to be present inside of mainstream packages if they were not used. Since we're now building SCLs, we are now enforcing a strict separation. Packages MUST be updated to restrict SCL macros to only those packages particularly approved as part of an SCL.

This part of guidelines was created in time when it looked like SCLs in Fedora are going to happen and they should be supposedly replaced by separate guidelines ... since this never happened, I would like to request either reverting the change:


Or change the text to this:

SCL macros are allowed to be present inside of mainstream packages, even if they are not used. It's up to the package maintainer whether the SCL macros are used. Package maintainer is responsible to make sure that these macros are not used when building the package as mainstream package (not as SCL).

== Reasoning ==

Fedora packages are often base for SCL packages in RHSCL and other collections. Currently, guidelines force package maintainers to keep separate versions and the work done in SPEC is doubled. Even if we had one spec file as base and would like to remove SCL macros for usage in main Fedora branches, the removing of the SCL macros is not easy to be done in automated way.

The SCL macros are specifically designed to be included even if they are not used and they don't have any influence on resulting packages if main scl macro is not set. According to the SCL concept, one SRPM may (deliberately by design) then be used to build packages for one or more collections, or ordinary packages without SCL.

If (by any mistake) SCL macros would be set, the build wouldn't end successfully anyway in koji, because the resulting image would be called differently.

IMHO, possibility of issues caused by using SCL marcos by mistake, is the only reason why SCL macros are prohibited. I believe this doesn't bring any real risks or the risk is not very probable. Not more probable than any other macros mistake. Or at least the risks are not worth the doubling work.

Just to not cause unnecessary confusion, this is not a request to add SCL macros wherever it is possible, it is just to remove the prohibition, that produces unnecessary maintainance work in some cases.

Note: In the distant past we've decided that allowing macros for other distributions and build systems violated the legibility requirements for spec files. The SCL macros would definitely violate this as well. If FPC wants to change this, they probably should change it at the root -- Modify the legibility guideline to allow spec files to be less readable if the reason is to make the spec file usable in other build systems and services. (openSUSE's open build system is probably the other major one.)

Second note: The reasons to prohibit SCL macros from the main Fedora packages are still valid. If SCL macros live in the main spec file then you raise another barrier of entry for anyone wanting to contribute to the mainstream Fedora package. At its heart, a spec file is an easy way to enable a system administrator to contribute to Fedora. If they can build and install a piece of software from source then they can understand a spec file and modify it. Adding all of the special macros that SCLs require drastically reduces that comprehension and makes it less likely for people to want to help maintain a package.

Based on my experiences in maintaining packages in Fedora that become SCLs, I don't see almost any interests in becoming maintainers of non-SCLized packages either, so the argument with creating bigger barrier is not something we'd really face. I also don't agree that the SCL drastically reduces comprehension -- we had several new packagers who had learned basic RPM macros just few weeks before we introduced them to SCL macros and I haven't seen any big issues.

So, simply said, the benefits to allow SCLs are much bigger than benefits of prohibiting them.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-12-03/fpc.2015-12-03-16.00.txt):

  • 581 Remove prohibition of SCL macros from Guidelines (geppetto,

  • LINK: https://fedorahosted.org/fpc/ticket/581 (geppetto, 17:51:57)
  • ACTION: Remove prohibition of SCL macros (+1:1, 0:0, -1:3)
    (geppetto, 17:59:05)

As an SCL user, where SCLs are a critical part of managing the Python 2->3 transition (http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html), I'm trying to understand how I benefit from the following chain of events:

  1. The SCL maintainers came up with a user demand driven technology building atop the Fedora/RHEL base, and offered to contribute it back upstream to Fedora
  2. FPC made it clear they didn't like the details of how the technology worked, and didn't want to promote it as a recommended technique within Fedora
  3. The SCL maintainers accepted this feedback, and approached the CentOS community about establishing the SCL upstream as a CentOS SIG instead
  4. The CentOS community had a stronger need for the feature (since they share the exact same technology base as RHEL, and hence their user community has similar needs), and accepted SCLs as a SIG technology
  5. Due to being upset with the course of action taken at "step 3" (i.e. work with a different upstream distro community, rather than changing the technology to be more acceptable to Fedora's leadership), FPC members are maintaining a distro-wide ban on any use of SCL macros in mainstream Fedora SRPMs, rather than delegating that readability vs cross-distro maintainability decision to individual package maintainers

That doesn't make any sense from a user benefit perspective - it reads like FPC members are prioritising distro politics over my interests as a Linux user in the Fedora/RHEL/CentOS ecosystem. Toshio gets to the heart of this in his first note, which is that the trade-off between cross-distro SRPM maintainability (whether for EPEL, RHEL/CentOS, SCLs, OpenSUSE, Mageia, or something else) and barriers to entry for folks coming to RPM packaging for the first time would likely be better delegated to individual package maintainers.

The essential problem I see with the status quo means that someone currently maintaining an SCL package would need to take on a lot of additional work to mainstream that package into Fedora, and the same applies for anyone else that already maintains an SRPM and would like to add it to Fedora as well (packagers for other Fedora/CentOS derivatives like Amazon Linux, Scientific Linux, FBOSS, and Photon also come to mind as potential sources of Fedora packaging recruits that are potentially inhibited from contributing by the current legibility guidelines, as those guidelines mean they can't just add Fedora as another RPM build target for their current SRPMs, they need to create and maintain entirely new Fedora specific ones)

I'll file a new ticket to that effect.

New ticket filed to follow up on Toshio's observation that the root cause of the dispute here is the interpretation of the legibility requirement as banning the use of cross-distro SRPMs in Fedora: https://fedorahosted.org/fpc/ticket/582

For the record, a reference to the full meeting log that make it clear that the reasons for maintaining the ban on SCL macros are political ones related to a personal dispute with the SCL maintainers rather than technical ones motivated by the interests of Fedora users: https://meetbot.fedoraproject.org/fedora-meeting-1/2015-12-03/fpc.2015-12-03-17.00.log.html#l-180

For the record, I still think that SCLs are the technically wrong way of doing what they are doing and that is my only reason for being against introducing them to Fedora.

But you can't question that they do the work and for users it is good solution for the problem of multiple versions available in parallel.

This is exactly what I'm questioning: the statement that it is a good solution. IMO it isn't. It "works", but at the cost of being a kludge and not following the FPG.

Metadata Update from @ncoghlan:
- Issue assigned to james

6 years ago

Login to comment on this ticket.