In https://github.com/mesonbuild/meson/issues/1790#issuecomment-301255334, @Conan-Kudo noted that one of the current challenges with SCLs is that they can't be used even as BuildRequires for packages in EPEL. This means that an EPEL package can't (for example) rely on the Python 3.5 SCL - it needs a native parallel Python 3.5 stack in EPEL.
From my perspective, the package development flow that makes the most sense would be Fedora -> SCL -> parallel stack in EPEL (since that should duplicate less work than having Fedora -> SCL and Fedora -> EPEL being entirely independent activities).
However, before trying to change a process, it's important to understand how the current process actually works (or doesn't work as the case may be), otherwise there's a significant risk of solving the wrong problem.
Relatedly, it isn't at all clear to folks new to the Fedora/RHEL/CentOS system when it makes sense to consider using Software Collections over EPEL packages and vice-versa: https://twitter.com/brettsky/status/863460803705397248
So this issue proposes adding a page to softwarecollections.org that specifically compares and contrasts how SCLo works with the way EPEL works. As a couple of examples of similar pages on a different service also aimed at tackling the problem of shared maintenance and delivery of newer components on long term stable distros:
Software Collections, by design, put their components into publisher and version scoped subdirectories of /opt/ (but replicate FHS within those subdirectories). This allows parallel installation without reliance on full independent container images (which is useful for developer workstations, build environments, and traditional mutable servers). Even when using container images, it means language runtimes installed for developer use can't conflict with language runtimes in the base operating system image. This layout also means that essential support metadata (publisher and version) is conveyed by the filesystem paths, even without querying other component metadata.
The downside of this approach is that it means SCLs will typically require activation prior to use, even when they're the only version installed - their binaries, shared libraries, etc aren't linked by default from the FHS locations.
In https://github.com/mesonbuild/meson/issues/1790#issuecomment-301255334, @Conan-Kudo noted that one of the current challenges with SCLs is that they can't be used even as
BuildRequiresfor packages in EPEL. This means that an EPEL package can't (for example) rely on the Python 3.5 SCL - it needs a native parallel Python 3.5 stack in EPEL.From my perspective, the package development flow that makes the most sense would be Fedora -> SCL -> parallel stack in EPEL (since that should duplicate less work than having Fedora -> SCL and Fedora -> EPEL being entirely independent activities).
However, before trying to change a process, it's important to understand how the current process actually works (or doesn't work as the case may be), otherwise there's a significant risk of solving the wrong problem.
Relatedly, it isn't at all clear to folks new to the Fedora/RHEL/CentOS system when it makes sense to consider using Software Collections over EPEL packages and vice-versa: https://twitter.com/brettsky/status/863460803705397248
So this issue proposes adding a page to softwarecollections.org that specifically compares and contrasts how SCLo works with the way EPEL works. As a couple of examples of similar pages on a different service also aimed at tackling the problem of shared maintenance and delivery of newer components on long term stable distros:
The key points to emphasise would be that:
/opt/(but replicate FHS within those subdirectories). This allows parallel installation without reliance on full independent container images (which is useful for developer workstations, build environments, and traditional mutable servers). Even when using container images, it means language runtimes installed for developer use can't conflict with language runtimes in the base operating system image. This layout also means that essential support metadata (publisher and version) is conveyed by the filesystem paths, even without querying other component metadata.