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".
Marty
_______________________________________________
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
