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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
