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.
Zbyszek
_______________________________________________
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
