On Thu, 17 Oct 2019 at 10:06, Przemek Klosowski via devel
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Stephen J Smoogen.