Re: Ursa Major (modules in buildroot) enablement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 6, 2018 at 11:21 AM Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
>
> >>>>> "FW" == Florian Weimer <fweimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux