On Tue, Nov 6, 2018 at 11:21 AM Jason L Tibbitts III <ti...@math.uh.edu> wrote: > > >>>>> "FW" == Florian Weimer <fwei...@redhat.com> writes: > > FW> Modules do not support parallel installations of different module > FW> versions. Many SCLs are constructed in such a way that this is > FW> possible. So I'm not sure if modules are a clear improvement over > FW> SCLs. > > And the really fun thing is that once the different versions are > installable in parallel you could just.... have them in different > packages. So SCLs aren't really an improvement over plain old packages, > either. > > So it seems to me that modules are useful specifically in the "not > parallel installable" case; they seem to be to simply be a framework for > handling sets of mutually exclusive packages (and the combinatorial > dependency explosion which results). Which I guess is reasonable, > though I always thought they would be the last resort when > you can't make two versions able to be installed in parallel. Instead > it seems like they're being pushed as the default, which just seems > backwards to me.
I think it only seems that way because there's a non-trivial number of useful packages (e.g. Node.js) that can't be trivially installed in parallel like Python can and which have regular, backwards-incompatible jumps and multiple supported upstream versions. This has always been a problem for Fedora; either users would hold their systems back on unsupported Fedora releases to maintain older versions, or else they'd stop using our packaged versions at all, which devalues us. Modules gives us the ability to allow us to ship whatever versions the maintainer is willing to maintain. Now, one thing that I think hasn't been made clear in this thread is this: Ursa Major is net-new functionality. With or without modules today, you can only have in the buildroot the set of things that you could get from DNF without being aware of module-specific commands. Modules with a default stream Just Work for buildroots. The improvement with Ursa Major is the ability to have a non-default version of software available *only at build-time*. As a hypothetical example, maybe python-sphinx has a major backwards-incompatible update that becomes the default in Fedora 30. The package you maintain will only build its docs with the older Sphinx. Without Ursa Major, you basically have two choices: 1) Stop building the docs until upstream catches up to Sphinx, or 2) Try to write a patch to support the new version of Sphinx. With Ursa Major, you potentially gain 3) BuildRequires the previous version of Sphinx for your package. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
