On Thu, 17 Oct 2019 at 10:06, Przemek Klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 10/16/19 7:36 PM, Kevin Kofler wrote: > > It was never designed to solve parallel installability problem. > > … which is exactly why it causes version hell. > > Could you expand on that? Since a modular system currently prevents parallel version installation, it may provide suboptimal/obsolete versions, but I wouldn't tap it as 'version hell', which in my mind describes a system with multiple installed versions installed all over the place, causing confusion and uncertainty as to the ABI compatibility and patching status. > [For the sake of this strawman... I am using libreoffice and evolution which are only used because they are highly used items.. they could be anylist of things like httpd and varnish or some other things you would use together but aren't being modulared together.] people are going to add things into their modules to make whatever software they need. If I find that I need libfoo2-2.34 in libreoffice and you need libfoo2-2.40 in evolution.. then only one of the two modules can be installed. You can either have libreoffice or you can have evolution. Furthermore whatever packages which were built against the non-modular libfoo2-2.30 will either not work or be uninstalled because the user decided they wanted libreoffice or evolution. Each module 'owner' would have been making the best decision with the time and energy they have to use modules for their problem: get the latest software out for the most releases as easily as possible. They will probably have tried to get libfoo2 updated in the core but found that the libfoo2 maintainer is not responding or a CVE came out and it had to be fixed now and the fix for libreoffice needed a version. So after this happens the libreoffice and evolution decide to work their modules together. That eventually turns into just one module .. when they run into a problem with the firefox module which now is pulling in a new libfoo2. They get pissed off and retire all of libreoffice and evolution (and whatever else got pulled in as the modular versions of X) or they combine with firefox. Packages are like a super saturated liquid below the freezing point. There are 20,000+ packages and ~400 active packagers. Little events are going to cause either tiny crystals to grow around a package (a module of 1 package like the RHEL perl-CGI) or a giant crystal (rust and java are probably going to grow until anything built with those languages will have to be in the module) and it will happen very very fast.. must faster than expected.. and like a crystal growth it will have lots of faults and crack open in ways not expected also. > Perhaps you are saying that a hypothetical system allowing packaged parallel installed versions provides the authoritative registry that tracks such dependencies, and therefore does not have these problems? > > > _______________________________________________ > 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 -- Stephen J Smoogen. _______________________________________________ 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
