> On Nov 21, 2016, at 7:23 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > Hi, > > I've been thinking about the implications of alternative/drop-in replacement > ports and ABI differences. > > IIUC, libressl and openssl are API-compatible alternatives that do not build > to ABI-compatible libraries. Yet I have noticed that ports use a path:-style > dependency declaration which allows users to chose to install either the one > or the other. > > Is there anything currently in MacPorts that avoids issues that will probably > arise when you install libressl and then pull in a prebuilt binary that will > supposedly be built against openssl?
You're right, nothing currently prevents that problem. I've complained about this method of handling libressl vs openssl before. > Idem for the classical use of path:-style dependency declarations where they > allow to install a -devel port. The standard and -devel port may not provide > a 100% compatible ABI; is it purely up to the port maintainer to ensure that > this never leads to issues with binary builds (and for the user's > responsibility if it does)? The same does not apply to -devel ports. -devel ports are just newer (usually development) versions of stable ports. Usually these may offer more functionality, but not less, and other port binaries are built linked to the default dependency (i.e. the stable version), so there is no problem. (There would be a problem if other port binaries were built against the -devel version, but they're not.) There is of course a problem if a -devel port increases the library version number. Fortunately, I can't remember the last time that happened with the -devel ports I maintain, so it's not a big problem, and in any case it would only affect the minority of users who elected to use the -devel version.
