On Thu, Jun 29, 2017 at 9:20 AM, Honza Horak <hho...@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: https://www.softwarecollections.org/en/docs/guide/#sect-Converting_a_Conventional_Spec_File 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): https://www.softwarecollections.org/en/docs/guide/#sect-Converting_Software_Collection_Scriptlets_into_Environment_Modules 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. Cheers, Nick. 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 _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
