On 02/07/2017 01:42 AM, Alice Wonder wrote:> The software collections looks like it might interfere with some of my > own packaging (repos that build upon EPEL to provide modern server > stack based on LibreSSL and a repo for modern multimedia)Where do you see a conflict? Those packages are structured to avoid conflict with the base platform, but installing into an alternate root (/opt/rh/<package collection>) and are normally active only when specifically enabled in a login session. That is, they're available when wanted but don't affect the system when they aren't.
On 02/07/2017 07:34 AM, Gordon Messmer wrote:> On 02/07/2017 01:42 AM, Alice Wonder wrote: >> The software collections looks like it might interfere with some of my >> own packaging (repos that build upon EPEL to provide modern server >> stack based on LibreSSL and a repo for modern multimedia) > > > Where do you see a conflict? Those packages are structured to avoid > conflict with the base platform, but installing into an alternate root > (/opt/rh/<package collection>) and are normally active only when > specifically enabled in a login session. That is, they're available when > wanted but don't affect the system when they aren't. >What I mean is conflicts in devel packages. What I mean is this - my LibreSSL package installs in /usr and not in /opt and that is intentional, so that it is not possible to have both opennsl-devel and libressl-devel installed at the same time, since they both are the same API. Here's why - If I build php against LibreSSL but some some of the PHP build dependencies are built against OpenSSL then those build dependencies will want openssl-devel. If both openssl-devel and libressl-devel are /usr then the packages will conflict and I know I have to rebuild the PHP build dependencies against LibreSSL before I can build PHP. But if LibreSSL was in /opt then RPM would have no problem having both libressl-devel and openssl-devel installed at the same time, and the build of PHP could potentially result in mixed implementation of the OpenSSL API - e.g. PHP is linked against LibreSSL but also is linked against Net-SNMP which is linked against OpenSSL - so that the dynamic loader then loads two shared libraries that provide the same API. That's what I am trying to avoid, and that is easiest to avoid by just using /usr as the prefix so that devel files have their headers in /usr/include and devel files for different implementations of the same API can not be installed at the same time.
On 02/07/2017 02:33 PM, Alice Wonder wrote:> That's what I am trying to avoid, and that is easiest to avoid by just > using /usr as the prefix so that devel files have their headers in > /usr/include and devel files for different implementations of the same > API can not be installed at the same time.None of that is particularly relevant. There are only 3 "devel" packages in the devtoolset-4 collection, and those are only for the developer tools. Using that collection for gcc, especially if you're only using that compiler for one package, isn't going to create the conflicts you're describing.
--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder <alice at domblogger.net> wrote:> What I mean is this - my LibreSSL package installs in /usr and not in > /opt and that is intentional, so that it is not possible to have both > opennsl-devel and libressl-devel installed at the same time, since they > both are the same API.That's the very problem that Software Collections endeavors to solve. If you install a non-standard package that conflicts with OS defaults, install it as a collection so that end users can choose whether to use the enhancement or the default, on a per-session basis.> But if LibreSSL was in /opt then RPM would have no problem having both > libressl-devel and openssl-devel installed at the same time, and the > build of PHP could potentially result in mixed implementation of the > OpenSSL API - e.g. PHP is linked against LibreSSL but also is linked > against Net-SNMP which is linked against OpenSSL - so that the dynamic > loader then loads two shared libraries that provide the same API.Does Net-SNMP expose the libraries and API it depend on? Does the loader only link on API signature or does it also look at the library name? Does Net-SNMP fail if it was built against OpenSSL but is loaded with LibreSSL? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus