----- Original Message -----
From: "Daniel P. Berrangé" <berrange(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Friday, June 19, 2020 5:58:28 AM
Subject: Re: RHEL 9 and modularity
On Fri, Jun 19, 2020 at 11:28:58AM +0200, Vít Ondruch wrote:
>
> Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a):
> > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr <johnmh(a)splentity.com>
> > wrote:
> >> The issues I've seen so far affect both Fedora and RHEL, but have
gotten
> >> a bit
> >> better in Fedora. For example, a major concern that has been much worse
> >> in
> >> Fedora than RHEL, for obvious reasons:
> >>
> >> One month you can do a fresh install, install a package that, as it
> >> turns out,
> >> is a module for some reason.
> >>
> >> Then you install a fresh system the next month, install the same
> >> package.
> >> Perform a dnf update on the previous system, and you'll find that you
> >> have a
> >> different version of the package installed, because you're tracking a
> >> different version of a default stream.
> >>
> > Can you give an example of where you've seen this? Because our
> > policies in Fedora forbid changing a default stream in a released
> > Fedora. There were a couple exceptions around Java/Maven and libgit2
> > in the past due to their default streams being broken
>
>
> Sorry, but I don't remember this as "their default streams being
> broken". AFAIR, there were multiple applications trying to use different
> version of libgit2 at the same time which is not possible. That is
> problem of modules design, not problem of the specific default stream as
> you put it.
That clashing libraries problem is the fatal design flaw in modularity
as it exists today.
We've made it possible for each module to ship arbitrarily different
versions of the same libraries, while all wanting to install into
the same directory prefix. Thus two separately maintained modules can
easily become mutually exclusive, which is a big pain for users who
need to use both concurrently. This is essentially the "DLL Hell"
problem.
The single shared /usr hierarchy only works (in the general case) when
you have a single stream where everyone agrees on using the same version
of each package.
I can only see this being solvable if non-default modules streams are
required to be built into a unique /opt prefix instead of /usr.
Or better, if all the work that has gone into maintaining separately
packaged libraries went into maintaining one version and fixing
associated dependent packages as necessary... Especially for Java and
libgit2.