On Tue, Nov 6, 2018 at 10:47 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Nicolas Mailhot: > > > My current understanding of modules benefits is that they’re just > > improved SCLs. ie something EL oriented that the average Fedora packager > > has little interest or use for. > > > > Practically, being improved SCLs just means: > > > > 1. rawhide has the latest version of each module enabled by default, > > 2. stable has the same version enabled by default if the module version > > is completely baked, and the previous one otherwise > > 3. epel has the same module version as stable enabled by default > > Modules do not support parallel installations of different module > versions. Many SCLs are constructed in such a way that this is > possible. So I'm not sure if modules are a clear improvement over SCLs. > I find myself repeating this reply over and over again in various places... 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) 2) Customers really *dislike* needing to modify their software to understand the SCL enablement process. 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.) This *is* a net improvement for the vast majority of deployments. _______________________________________________ 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
