On Sun, May 16, 2021 at 5:01 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Fri, May 14, 2021 at 02:57:14PM -0400, Matthew Miller wrote: > > On Fri, May 14, 2021 at 06:38:33PM +0200, Miro Hrončok wrote: > > > I wouldn't say so. I'd say "package both versions as separate > > > non-modular RPM packages with unique names" is the general answer > > > when different versions of the package are desired. > > > > > > However, the problem here is different. We don't want 2 different > > > versions packaged in Rawhide AND 2 different versions packaged in > > > ELN. We want to allow package versions in ELN and Rawhide to be > > > different. > > > > This is exactly a case that modularity is supposed to handle. Two different > > versions packaged only one time each, built for both targets automatically, > > with one the default on target A and the other the default on target B, > > output, but with either version selectable in either target. > > I think this has been discussed at some point ;----] > but since the topic has been raised: > > no, doing modules here is very much the wrong answer. For three reasons: > 1) it's more work for the maintainer, > 2) it's much harder to consume for other packagers, > 3) users are more happy with separate packages. > > We don't have firefox-esr in the distro, but we actually have firefox-x11, > and to a large extent doing a different version is similar to doing a build > with different flags: > 1) either > a) the maintainer adds a separate section in %build and then > %package+%files sections (same version, different build flags) > or > b) the maintainer requests a compat package (no review required!), and > just tweaks the .spec as necessary (different versions). > Compared with that, a module would require ... a module, and a new workflow > for the packager and users *and* all the work with a non-modular package, > since the module is just a wrapper around the actual spec file which > needs to be maintained in two versions. > 2) Other packagers can do Requires:firefox-x11 and be done. With modules, > they need to modularize, and are generally into a world of pain, e.g. the > lifetime rules for the module don't follow the release cadence. > 3) Users do 'dnf install firefox-x11' and can have both versions present > (and even running!) at the same time. With modules, you get a learn a new > workflow but no parallel-installability. > > If we want the "main" version to be different, then that's also easy > with packages: a few lines of '%if <whatever> Provides: ...' and one > of the subpackages becomes the default. > > tl;dr: let's solve ELN-branching problems, but let's not use that to > reintroduce modules. > I don't think that modules are necessarily universally terrible for this solution. But that said, we probably don't want Firefox ESR in ELN anyway, since we'd want to be tracking the latest stuff to make sure everything is sane in Fedora ELN, and *then* transition the Firefox package to Firefox ESR post-branching for a CentOS Stream release. It's more important that we track the latest content from Rawhide and have it build in an EL-ish context than to implement all the different policy freezes that RHEL does in Fedora, since we want to be fluid enough to do differently in a future RHEL release. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
