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

2016-12-30 Thread René J . V . Bertin
On Friday December 30 2016 17:25:20 Mojca Miklavec wrote: > I would agree that it would be helpful to have some "more advanced" > version of dependency specification available. The depspec syntax doesn't necessarily have to be more complicated. Ports that require more advanced functionality could

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

2016-12-30 Thread Mojca Miklavec
On 30 December 2016 at 11:32, René J.V. Bertin wrote: > Hi, > > I'm coming back to this discussion because of something that came up > elsewhere. > > I think we had a consensus a while back that the implementation of the > support for using libressl at user discretion left a bit to desire. I agr

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

2016-12-30 Thread René J . V . Bertin
Hi, I'm coming back to this discussion because of something that came up elsewhere. I think we had a consensus a while back that the implementation of the support for using libressl at user discretion left a bit to desire. There could be a protection against installing binary packages built agai

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

2016-11-22 Thread René J . V . Bertin
On Tuesday November 22 2016 15:14:15 Ryan Schmidt wrote: > The same does not apply to -devel ports. -devel ports are just newer (usually > development) versions of stable ports. I beg to differ, it *can* apply to -devel ports that provide a newer version of the release port. I didn't invent the

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

2016-11-22 Thread Lawrence Velázquez
> On Nov 22, 2016, at 4:54 AM, Mojca Miklavec wrote: > >> On 21 November 2016 at 14:23, René J.V. Bertin wrote: >> >> 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 bui

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

2016-11-22 Thread Ryan Schmidt
> On Nov 21, 2016, at 7:23 AM, 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 h

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

2016-11-22 Thread René J . V . Bertin
On Tuesday November 22 2016 10:54:22 Mojca Miklavec wrote: >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

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

2016-11-22 Thread Mojca Miklavec
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 noti

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

2016-11-21 Thread René J . V . Bertin
On Monday November 21 2016 14:23:40 René J.V. Bertin wrote: PS >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? And with that I meant anything ready

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

2016-11-21 Thread René J . V . Bertin
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 all