Re: Best practice for port that are meant to be statically linked, or how should we handle boringssl

On Sun, Nov 26, 2023 at 11:07:21PM -0800, Xin Li wrote:
> Hi,
> 
> I recently noticed that security/boringssl is treated in a similar way
> of OpenSSL and LibreSSL.

Technically, `security/boringssl' cannot be treated similarly, i.e. it
cannot be made one of possible SSL providers (via USES=ssl) because of
circular dependency (it requires CMake which itself requires SSL).

> Although boringssl is derived from OpenSSL, it's usually meant to be
> statically linked into the resulting binary, because there is no
> guarantee of ABI stability across different releases and the caller
> is expected to evolve fast enough to follow the latest version of it.

I was playing with that idea to get `www/envoy' packaged, later found
out there is OpenSSL-based fork and decided to go that way, but could
not complete the quest. :(

> OpenBSD seems to be going though the statically linked route and they
> install boringssl into ${PREFIX}/eboringssl instead of the regular
> ${PREFIX}.  This way, it's no longer conflicting with other OpenSSL/
> LibreSSL installation (technically, it still is, but only if the binary
> links against both OpenSSL/LibreSSL _and_ boringssl).
> 
> Should we follow this?  And is using something like ${PREFIX}/eboringssl
> a good model?  (I think ultimately we need something like it).

I wouldn't mind, albeit ultimately I'd rather see Google push their
changes in the stock OpenSSL and bury their silly fork.

./danfe