On Sun, May 16, 2021 at 5:01 AM Zbigniew Jędrzejewski-Szmek
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:
a) the maintainer adds a separate section in %build and then
%package+%files sections (same version, different build flags)
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
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
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!