On Tue, 2020-06-16 at 08:08 -0400, Neal Gompa wrote:
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community.
You're right, it's a catch-22. But so far we've been discussing "latest Leap" only in this thread, not everything that SUSE is supporting for enterprise customers. In general, it's worth discussing for every new rpm feature whether it's adoption on TW/Leap/SLE really makes packagers' lives easier. I understand that your PoV is different from the average SUSE person's PoV, as you do a lot of cross-distro work. I'm certainly more conservative than you are. I wouldn't consider starting to use a build feature only because it's available in Fedora.
It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to packagers. And if rpm functionality needs to be backported or enabled for the Fedora community, the process to get them turned on isn't onerous. It's mostly playing the waiting game for the next RHEL point release to get them to show up, but that's *at most* six months now.
For example, getting zstd payload support turned on RHEL was nowhere near as painful as it was to get it turned on in SLE. And the endless catch-22 conditions that I have been peppered with since it was first brought up after Fedora switched to zstd payloads in Fedora 30 drives me bonkers. It's literally required more cleverness than I'd like to admit to get it turned on in SLE 15 SP2, and I'm *still* waiting despite the fact it's been switched on there because of some unwritten rule that Tumbleweed has to be backwards compatible with Leap 15.0[2].
Playing devil's advocate: what's the actual benefit of zstd, other than being "modern"? It uncompresses faster, ok. But when we install or update packages, what percentage of the time is actually spent in decompression, in contrast to downloading, possibly applying deltas, and installing (oh, and rebuilding the intird)? My personal gut feeling is that the net effect of the compression algorithm on the average user's experience is almost negligible, even if the numbers for the algorithm's performance alone look impressive. I don't recall how many times the compression algorithm has been changed since I've been using rpm-based distros. Every time it happened, it's been causing hassle for me, because you suddenly can't unpack packages from newer distros on older ones any more, and I always needed to work on older distros, too. I'm no fan of this sort of change in general.
In Fedora, packagers are free to adopt newer rpm features that are not backwards compatible with RHEL because the Dist-Git system lets you branch packages for specific target releases (and is the default behavior). You can have separate maintainers for Fedora and EPEL branches, and they can diverge to support those distributions. While many packagers maintain unified spec files across all branches (I do for a lot of them), nobody is required to. As an example, I do maintain separate ones with capnproto for Fedora[3] and EPEL 7[4] (and I have done so in Fedora releases in the past, too), but I maintain a unified one for Pagure[5]. I diverge when I feel it's necessary, and no sooner. And many packages have different maintainers for Fedora and EPEL, with different spec files.
We don't have dist-git, but other than that, I don't see what of the above would be impossible on openSUSE. I'm all for trying to provide something like epel-rpm-macros, if that's possible.
This is a completely crap situation in openSUSE, because it means that it's extremely hard to improve the quality of life for packagers. This tug of war where forward progress loses to SLE often means that openSUSE itself can't adopt new RPM features or capabilities to simplify packaging. Nobody wants to consider using it in openSUSE because we can't adopt features in openSUSE Tumbleweed that break SUSE Linux Enterprise. It's why we didn't drop the (useless) BuildRoot tag definition until SLE 11 fell out of support. It's why packagers *still* don't correctly mark license files in package file lists (SLE 12 didn't support it properly until SP3). The community has little influence over what goes on in SLE at that level, and the only way stuff moves forward is if SLE is "trapped" into enabling functionality or backporting stuff. This is horrible and we shouldn't have this problem to begin with!
I *really* hope the "closing the leap gap" thing means that this gets better, but I'm not sure it will...
It's certainly not on top of the agenda (yet). But SUSE has an interest in the backports project, which would in turn benefit from having more packages available for Leap. I do think that SUSE would be interested in improving this situation. Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org