Re: [alpine-devel] TLS library provider for makedepends
I think it's inappropriate for libressl to be considered a replacement for
openssl. Whether it's secure or not, the project has not kept its API
compatibility promises, therefore making it impossible to compile software
that is necessary for webapps such as taiga. Consequently, I support
returning to openssl as system default, and only keeping libressl around
for software which actually requires it.
On Tue, Nov 7, 2017 at 12:36 AM Timo Teras <timo.teras_at_iki.fi> wrote:
> On Mon, 6 Nov 2017 20:04:31 -0600
> "A. Wilcox" <awilfox_at_adelielinux.org> wrote:
> > However, Adélie targets 32-bit x86, 32-bit MIPS, 32-bit PowerPC, and
> > 32-bit ARM. Obviously this is therefore a quite significant issue for
> > us. We do not want to have to soft-fork every package in the Alpine
> > aports repository that depends on OpenSSL or LibreSSL to change the
> > library provider. I am soliciting ideas on how to move forward.
> > My own idea would be to make a libssl-dev virtual that is satisfied by
> > libressl-dev on Alpine and openssl-dev on Adélie. We can use the new
> > provides_priority to accomplish this, and then we only have to
> > soft-fork the OpenSSL package.
> > Other ideas (that do not include dropping 32-bit architectures from
> > Adélie) are welcome. Let's discuss.
> This sounds like good idea to me. We don't need to even wait for
> provides_priority stuff, just use versioned provides since the two
> packages cannot co-exist.
> provides="libssl-dev=1" or similar for the package in aports that
> should be used, and apk will automatically use it. And update all
> makedepends for the new package name.
> As alternative, on Adelie, you could just do in openssl-dev
> provides="libressl-dev=99999" and it would be preferred over openssl.
> But would be nice to get rid of the package specific name and migrate
> to 'libssl-dev' or 'ssl-dev'.
> Other thoughts?
-- Kiyoshi Aman
Received on Tue Feb 06 2018 - 22:29:05 GMT