On Fri, Jun 19, 2020 at 08:06:29AM -0500, Martin Jackson wrote:
On 6/19/20 7:46 AM, Daniel P. Berrangé wrote:
On Fri, Jun 19, 2020 at 02:32:19PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote:
[...]
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.
Are you trying to re-invent the SCLs?
I'm not trying to do anything myself, just pointing out that I believe
modularity is broken by design because it leads to the need to have
mutually incompatible versions of things installed at the same place
at the same time. SCL was one concept that nicely avoided this problem,
by giving users the ability to have multiple versions of a stream
installed in parallel.
Flatpaks and containers are alternative ways to let users deploy
different versions of software without any clashing with the default
package set provided by the distro.
To be fair, while SCL's do solve this problem, they do so via subtle
but really important changes to user behavior. In my $work
environment we had lots of users that preferred to, for example,
compile their own versions of Python rather than use the SCL version.Â
While the restrictions SCL imposes make sense if you understand the
underlying plumbing with linking and so on, many users (even power
users) want /usr/bin/python in a shebang line.
Modularity attempts to solve the user experience problem by
effectively shifting this complexity to the admin side of the
equation. So if the only thing you care about is getting
/usr/bin/something (and you have other things that depend on
conventional pathing for any of a host of reasons), you can get it.
I agree in general that the problems that modularity solves haven't
been worth the complexities in the ecosystem that they've generated.Â
There are several other ways to install multiple pythons, and make
them installable in parallel that are easier than SCL (python2 vs.
python3 in /usr/bin).
I use flatpaks on Fedora (Discord and okular), and I've really enjoyed
the experience with them. I'm not sure how well that would translate
to the server environment though, but that general approach seems to
do a good job of preserving user experience while isolating
potentially troublesome conflicts in a way that doesn't mess up the
"base system".
Both of your points are valid. Daniel's point of the shared install namespace
but delivering multiple conflicting versions of files will lead to problems.
There is no amount of covering things up that escape that reality.
[And by conflicting files, I have taken it to mean I have libsomething version
2.0 and libsomething version 2.1. Both deliver libsomething.so.2 (that's what
other programs will list as a DT_NEEDED) but because of life being what it is
in the world of Linux distributions, those libraries actually carry different
symbols even though they advertise the same SONAME. None of that matters
though because at the dnf level the NVR's of the packages are
libsomething-2.0-1 and libsomething-2.1-1 and dnf is enforcing installation,
upgrade, or downgrade based on that information.]
Like you say, SCLs get around this fact by impacting the user experience.
It's not terrible, but it could be better. Modularity has, as I see it, not
yet clearly defined this reality. We could enforce uniform SONAME rules,
install things in separate prefixes, make use of DT_RPATH, or any of a number
of other mechanisms to let files from packages and modules coexist. And my
example here doesn't even address languages like Python or Perl, but I feel
those offer path management flexibility where additional subdirectories could
be added and not collide with files of the same name from another package.
I find flatpaks really nice from a user perspective. I have not spent a lot
of time building them. I went through the docs and built an example one for
myself and it was easy, but I did not get in to a lot of details.
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
