port:libressl vs port:openssl, path-style variants and prebuilt binaries

Mojca Miklavec mojca at macports.org
Tue Nov 22 10:54:22 CET 2016


On 21 November 2016 at 14:23, René J.V. Bertin 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?
>
> 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)?

According to my understanding, ports that depend on either of multiple
ABI-incompatible libraries should use variants to pick one or the
other, path-style is just the wrong workaround/shortcut (I don't know
if  openssl/libressl are ABI-incompatible, I'm just taking your word
for it, but if they are, the same holds for those two).

What makes the situation super complex is that MacPorts currently
doesn't offer any easy way to do the switch. Ideally (in my opinion)
there should be a mechanism to do the switch with a single command
(and replace/reinstall all ports "foo +openssl" with "foo +libressl").
A similar problem is making the situation with Perl so bad.

What I did in case of wxWidgets was the following:

    PortGroup wxWidgets 1.0
    # alternatives: wxWidgets-2.8 wxGTK-2.8 wxPython-3.0 ...
    wxWidgets.use wxWidgets-3.0
    depends_lib-append port:${wxWidgets.port}

but I made wxWidgets co-installable, so it didn't hurt anyone if some
ports remained linked against wxWidgets 2.8. In case of libressl this
would be slightly more painful.

If you asked this question in the spirit of what should be done with
Qt, you could easily pick a similar approach as I did with wxWidgets
instead of using path-style dependency.

There is some unfinished code (from summer of code) in master that
should be better at resolving dependencies of ports with variants.

Mojca


More information about the macports-dev mailing list