Hi Jaco,

Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
> 
> 1.  Nobody is AGAINST libressl per sé,

Michał gives me a distinctly different impression.


> 2.  A number of people are AGAINTS the effort involved to make
> libressl work for various packages.

Yes, and I've written that I am as well.


> Without the latter, libressl is dead

On this I disagree.


> since it can't install concurrently with openssl.

Again, that need not be the case, and I'm looking into what's
possible with little to no effort:


Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same
directory is not possible since file names are the same.

Installing both openssl and libressl .so:s in different directories is
not extremely useful (but perhaps still worthwhile) since one dep for a
given package may pull in openssl and another dep may pull in libressl -
even if path stuff is resolved neatly this doesn't work at load time.
This is only useful for the case of packages explicity needing
libressl, e.g. because of (ab?)use of internals, which have no deps
which can not also use libressl without constant overhead in Gentoo.
Maybe openntpd actually falls in this category.

Installing both openssl and libressl .a files in different directories
seems both useful and straightforward. I don't object to openssl being
favored for /usr/lib here, libressl gets a directory of its own, but
libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
Obviously this will only be useful for packages wanting to statically link
with libressl lib{crypto,ssl} but I think that's far better than removing
libressl.

Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl}
code of course) in /usr/lib also seems both useful and straightforward.
I expect this to be the default provider for (a new) virtual/libtls.


The latter two cause no conflicts and have no running overhead cost.


> Again, this will mean for libraries that they will need to have
> multi-implementation installations again

This is interesting; I suppose that this is supported very well by Nyx,
and I think it would be a great addition to Gentoo, but in any case it
will not be trivial, and I wouldn't want to make it a requirement for
having /some/ libressl code on Gentoo systems.

Hence I propose to redefine the meaning of "support for LibreSSL" to
what works well without causing lots of overhead. Again: It's not
reasonable for Gentoo to patch the world, but we should model it as
accurately as possible.


> So how do you deal with package-b-libressl vs package-b-openssl in terms
> of dependencies?

I've mentioned a couple of ideas in this thread but they're all
non-trivial and I propose to not solve this problem for now and
settle for less than a full install until someone finds a good,
manageable solution.


> Lots of very finicky risks that needs to be eliminated wih installing
> both openssl and libressl concurrently.

So again, the point is to redefine what "libressl installed" means
such that the problems are avoided, accepting that libressl
lib{crypto,ssl}.so may not get installed, at least for now,
until there's a good solution - which is really orthogonal to
libressl. Quite probably the same solution could then apply to the
other packages in similar situations (ffmpeg/libav, imagemagic, etc.).


> Someone (Michał?) mentioned it's more pain than gain currently.  And
> unless someone is willing to change that, I seriously doubt anything
> you say is going to carry much weight.

I hope it's becoming clear that what I am saying is about /how/ to
change that, and that should carry weight. Consider it brainstorming
solutions if you will.


> having written my fair share of code -

Same.


> the level of ask that you're asking for is much, much larger than I
> think you realise.

I hope what I am asking for is becoming clear. I wrote fairly early
in the thread that it's something other than the status quo.


> mysql and mariadb started out very similar, and now there are two major
> projects, and parts of it are installable separately (client libs).

Off-topic, but I'm really happy about MariaDB! I remember helping with
a MariaDB developer meeting in the early days and I was very excited
that most long-time developers decided to join Monty on MariaDB. Ever
since, MySQL is irrelevant to me. But I do appreciate that people who
are stuck with some Oracle support contract can still use it in Gentoo.


> I trust (hope) that this will give you a small amount of insight into
> what you're asking.

I thought it was clear for a good number of mails that I'm /not/ asking
to continue ensuring that openssl and libressl are interchangeable in
Gentoo;

I'm asking to ensure that libressl stays available /in some capacity/ even
if that can only be as a special case, and it looks like that would
require only very little upfront effort and zero recurring effort.


Thanks a lot for your thoughtful response! I hope I could clarify some things.


Kind regards

//Peter

Reply via email to