On Tue, Nov 6, 2018 at 6:06 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > <snip> > > I find myself repeating this reply over and over again in various places... Sorry about that. > The feedback that we (Red Hat) got about SCLs that was filtered down > to Engineering was this: > > 1) Customers really like having the option to install the version of > software that their applications needs from a trusted source (the OS > vendor/distributor) Not surprising, especially when it comes to RHEL and its quite long life cycle. > 2) Customers really *dislike* needing to modify their software to > understand the SCL enablement process. Really not surprising. Not that I find SCLs dis-likeable, but they require active involvement (like virtualenv and other similar things) while the trend is to make things JustWork(tm) (off the top of my head, "vagrant up", "docker run"...) > 3) Customers very rarely need to install different versions of the > same software on the same system. They use containers or VMs for > separate applications. > > So with Modularity, we opted to drop the parallel-installability > requirement in favor of parallel-*availability* and the ability to > keep the packages installing in the standard locations (/usr/bin, > /usr/lib64, etc.) I missed that change, so that's one less peeve for me. > This *is* a net improvement for the vast majority of deployments. I sort-of put Fedora modules, Snaps and Flatpaks in the same bags and at least for Snaps and Flatpaks it has always been a disaster for me (only AppImage ever worked for me with that flavor of packaging). Granted, it's not often that I need them so I haven't tested for a while now, but it never ever worked for me. Regarding modules, I superficially followed the early discussions (things like the modulemd format, initial goals etc) but as soon as the SIG was set up I lost track. I'm actually happy that the DNF plugin materialized as a "dnf module [...]" sub-command, and I only hope it won't break Fedora as I love it: First (and then stable for 13 months every 6 months). Dridi _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
