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.