[scl.org] SoftwareCollections Port

Nick Coghlan ncoghlan at redhat.com
Thu Jun 29 06:08:32 UTC 2017

On Thu, Jun 29, 2017 at 9:20 AM, Honza Horak <hhorak at redhat.com> wrote:
> SCL concept requires two basic things:
> * change location where the files are installed by changing default RPM
> macros (I expect something like that exists in the .deb packages as well)

A point worth noting about the way this works is that the RPM spec
file itself needs to be updated to be "SCL aware", and use the SCL
macros in the right places:

So SCLs for Debian would presumably need to do something comparable in
the Debian control file, and thus end up with a similar distinction
between "conventional packages" and "SCL enabled packages".

> * change the environment variables like PATH, etc. so the binaries and
> libraries are found on the alternative path. This part should be same in
> Debian as on RHEL.

A variant potentially worth exploring on the runtime side of things
would be following through on the current environment modules
generation and seeing if that could be made the default way of working
on Debian (et al):

That way, the main aspect that SCLs would be contributing would be the
"/opt/<publisher>/<collection>" (filesystem) and
"<publisher>-<collection>"(package name) conventions for parallel
installation support, with the existing "module" command handling the
activation process.

So yeah, as far as I'm aware, SCLs for non-RPM systems should
definitely be technical feasible, but it wouldn't be trivial either.


P.S. While we're not aware of any way to avoid per-package changes if
you actually want to support parallel *installation* of packages, I
figure it's worth mentioning that the Fedora Modularity project is
currently looking at less intrusive ways of supporting parallel
*availability* of different package streams that don't require updates
to each individual package: https://docs.pagure.org/modularity/

As a trade-off though, going down that path is requiring changes to
the package management system in Fedora itself, so it isn't readily
usable atop existing systems the way SCLs are.

Nick Coghlan
Red Hat Platform Engineering, Brisbane

More information about the SCLorg mailing list