#756 Please revert ban of SCL macros
Opened 2 years ago by vondruch. Modified 2 years ago

SCL macros were accidentally banned in Fedora by this change [1]. This change was supposed to be followed by reviewing SCL packages and approving SCLs in Fedora [2]. However, this never materialized.

Could you please either 1) revert the change [1] or alternatively 2) drop all the references to SCL and let people do what they consider is the best for their .spec files.


IIRC, SCLs were not banned accidentally, but deliberately, because does not have nor support them.

Currently there is a support: Modular modules allows injecting macros and packages into a build root independently from standard Fedora release build targets. That means a packager can build an SCL using the module build service without any interaction with release engineering.

Furthermore, just banning something because it's not currently used in Fedora seems to be quite rare. Just look at how much support we still have for ppc, s390, or downstream builds in general (which are definitely not Fedora).

For many package maintainers, the ability to share RPM spec files across distributions and branches reduces maintainer overhead, and that outweighs the increase in complexity resulting from having non-Fedora items in spec files.

Like @fweimer said I use the scl macros just like other macros for Fedora, EPEL or other downstream distros to make it possible to provide the "pure fedora package" (actually derived from upstream) to a larger audience to users of EPEL and various downstream Fedora distros that consume packages through COPR or softwarecollections.org. Even though the scl macros aren't enabled during package build by default on Fedora itself, it is really helpful to make the latest Fedora package available as an SCL too so that it can be tested and used beyond the latest/core Fedora.

It's important that specfiles which are part of the distribution be comprehensible in general. Packing them in with things which are not relevant for Fedora reduces maintainability and readability, and costs the Fedora community as a whole. That's why things like SCL macros and random things for cross-compatibility with other RPM-based distributions are not permitted in Fedora spec files.

I categorically object to any attempt to change that. We need specs to be simple, readable, and comprehensible. Opening things up to SCL macros or other non-Fedora things works against those goals.

Having simple, readable and comprehensible specs are a good goal. That really helps with maintainability. And obviously specs shouldn't contain macros that are totally unrelated and not relevant for the Fedora related projects. But the SCL macros are simple and straightforward. The packages that use them often only use 1 or 2 of them (most likely just the scl conditional and the scl_prefix macro). They greatly help with maintaining a single spec for Fedora, EPEL, CentOS, softwarecollections. And are well documented, on the Fedora wiki itself. In the 5 years that I have been using them I haven't heard of any complaint from any co-maintainers that they are incomprehensible. The macros constructs used to support the various different architectures are probably far more complex.

It's important that specfiles which are part of the distribution be comprehensible in general.

As long as the toolchain packages (GDB in my case) are maintained by Red Hat employees they will be maintained with the SCL macros (dot). The only question is how the .spec files should be pushed to Fedora. If Fedora really disallows the SCL macros it will just lead to a preprocessing step removing the SCL macros during push to Fedora. Therefore Fedora .spec will be no longer a real source but just an intermediate compilation format. That is more difficult to maintain and more prone to errors in both directions of imports.

Besides that those few lines using SCL macros are negligible compared to the whole .spec size (even without its %changelog).

I categorically object to any attempt to change that. We need specs to be simple, readable, and comprehensible. Opening things up to SCL macros or other non-Fedora things works against those goals.

@tibbs I think this is a strong argument. I want it to be easy to for anyone to contribute to any Fedora package, without needing even more arcane knowledge than we already require.

But, in practice, many specfiles are complicated (bordering on insane) for reasons which have nothing to do with these types of macros. Look at the horrific festival.spec (which is largely my fault from a decade ago). It feels like there is some degree of aspirationally-high standards in one case, while we've got a lot of general chaos. Is the argument primarily that we want to make sure we're only moving in a positive direction, or is there more to it than that?

I think it's clear that there are some advantages to allowing the SCL macros to be in, even though there are also possible disadvantages. Is there a way we could test or somehow quantify or measure the impact on a) current proven packagers and others, b) new contributors, and c) drive-through PR contributions for packages with these macros and those without?

I know you didn't just intend to argue that some specs are bad, so we should allow any spec to be slightly worse.

My point is that I don't see the upside here. Either we're arguing for maximum specfile cleanliness wherever possible or we aren't. I've spent a big chunk of my time with Fedora working towards cleaning things up, making specs simpler and making the packaging guidelines something you can follow and come out with a clean package. If that means that we have to keep some unpleasantness out so that some maintainers might need to keep a block of macros out of Fedora specs which have some use in other distros, then my opinion is that it's worth it. I understand that others might have a different opinion.

The fact that this relates to SCLs, and that some people are going to snipe in with lies about the process that led to them not being accepted, is certainly unfortunate but I believe my views here have been consistent for many years on this particular issue and those not related at all to SCLs.

I know you didn't just intend to argue that some specs are bad, so we should allow any spec to be slightly worse.

Welllll, it sounds bad when you put it that way. :)

But, actually, I do want to argue a little bit along those lines. It is, after all, RPM specfiles we are dealing with, and just by the inherent nature of the legacy of the format they're never going to be perfectly easy and elegant. That's what I meant by "aspirationally-high" — we can't really get to maximum specfile cleanliness ever, not with a very radical design of what a specfile is. Given that, I'm not really convinced that allowing in some inelegant cruft in certain circumstances necessarily really makes the situation practically worse. And I'm definitely more concerned with the pragmatic effect than with the theoretical.

I definitely appreciate your goals and the work you've put towards them and absolutely believe that that effort has made both Fedora and RHEL considerably better.

Login to comment on this ticket.

Metadata