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. 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]. 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. 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... [1]: https://src.fedoraproject.org/rpms/epel-rpm-macros [2]: https://github.com/openSUSE/rpm-config-SUSE/pull/26#issuecomment-636795495 [3]: https://src.fedoraproject.org/rpms/capnproto/blob/f32/f/capnproto.spec [4]: https://src.fedoraproject.org/rpms/capnproto/blob/epel7/f/capnproto.spec [5]: https://src.fedoraproject.org/rpms/pagure/blob/master/f/pagure.spec -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org