----- Original Message ----- > From: "Daniel P. Berrangé" <berrange@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxx> > > > 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. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange > |:| > |: https://libvirt.org -o- https://fstop138.berrange.com > |:| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange > |:| > _______________________________________________ > 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 > _______________________________________________ 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
