1 |
Hi Jaco, |
2 |
|
3 |
Jaco Kroon wrote: |
4 |
> So a few points that I picked up during this discussion. |
5 |
> |
6 |
> 1. Nobody is AGAINST libressl per sé, |
7 |
|
8 |
Michał gives me a distinctly different impression. |
9 |
|
10 |
|
11 |
> 2. A number of people are AGAINTS the effort involved to make |
12 |
> libressl work for various packages. |
13 |
|
14 |
Yes, and I've written that I am as well. |
15 |
|
16 |
|
17 |
> Without the latter, libressl is dead |
18 |
|
19 |
On this I disagree. |
20 |
|
21 |
|
22 |
> since it can't install concurrently with openssl. |
23 |
|
24 |
Again, that need not be the case, and I'm looking into what's |
25 |
possible with little to no effort: |
26 |
|
27 |
|
28 |
Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same |
29 |
directory is not possible since file names are the same. |
30 |
|
31 |
Installing both openssl and libressl .so:s in different directories is |
32 |
not extremely useful (but perhaps still worthwhile) since one dep for a |
33 |
given package may pull in openssl and another dep may pull in libressl - |
34 |
even if path stuff is resolved neatly this doesn't work at load time. |
35 |
This is only useful for the case of packages explicity needing |
36 |
libressl, e.g. because of (ab?)use of internals, which have no deps |
37 |
which can not also use libressl without constant overhead in Gentoo. |
38 |
Maybe openntpd actually falls in this category. |
39 |
|
40 |
Installing both openssl and libressl .a files in different directories |
41 |
seems both useful and straightforward. I don't object to openssl being |
42 |
favored for /usr/lib here, libressl gets a directory of its own, but |
43 |
libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically. |
44 |
Obviously this will only be useful for packages wanting to statically link |
45 |
with libressl lib{crypto,ssl} but I think that's far better than removing |
46 |
libressl. |
47 |
|
48 |
Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl} |
49 |
code of course) in /usr/lib also seems both useful and straightforward. |
50 |
I expect this to be the default provider for (a new) virtual/libtls. |
51 |
|
52 |
|
53 |
The latter two cause no conflicts and have no running overhead cost. |
54 |
|
55 |
|
56 |
> Again, this will mean for libraries that they will need to have |
57 |
> multi-implementation installations again |
58 |
|
59 |
This is interesting; I suppose that this is supported very well by Nyx, |
60 |
and I think it would be a great addition to Gentoo, but in any case it |
61 |
will not be trivial, and I wouldn't want to make it a requirement for |
62 |
having /some/ libressl code on Gentoo systems. |
63 |
|
64 |
Hence I propose to redefine the meaning of "support for LibreSSL" to |
65 |
what works well without causing lots of overhead. Again: It's not |
66 |
reasonable for Gentoo to patch the world, but we should model it as |
67 |
accurately as possible. |
68 |
|
69 |
|
70 |
> So how do you deal with package-b-libressl vs package-b-openssl in terms |
71 |
> of dependencies? |
72 |
|
73 |
I've mentioned a couple of ideas in this thread but they're all |
74 |
non-trivial and I propose to not solve this problem for now and |
75 |
settle for less than a full install until someone finds a good, |
76 |
manageable solution. |
77 |
|
78 |
|
79 |
> Lots of very finicky risks that needs to be eliminated wih installing |
80 |
> both openssl and libressl concurrently. |
81 |
|
82 |
So again, the point is to redefine what "libressl installed" means |
83 |
such that the problems are avoided, accepting that libressl |
84 |
lib{crypto,ssl}.so may not get installed, at least for now, |
85 |
until there's a good solution - which is really orthogonal to |
86 |
libressl. Quite probably the same solution could then apply to the |
87 |
other packages in similar situations (ffmpeg/libav, imagemagic, etc.). |
88 |
|
89 |
|
90 |
> Someone (Michał?) mentioned it's more pain than gain currently. And |
91 |
> unless someone is willing to change that, I seriously doubt anything |
92 |
> you say is going to carry much weight. |
93 |
|
94 |
I hope it's becoming clear that what I am saying is about /how/ to |
95 |
change that, and that should carry weight. Consider it brainstorming |
96 |
solutions if you will. |
97 |
|
98 |
|
99 |
> having written my fair share of code - |
100 |
|
101 |
Same. |
102 |
|
103 |
|
104 |
> the level of ask that you're asking for is much, much larger than I |
105 |
> think you realise. |
106 |
|
107 |
I hope what I am asking for is becoming clear. I wrote fairly early |
108 |
in the thread that it's something other than the status quo. |
109 |
|
110 |
|
111 |
> mysql and mariadb started out very similar, and now there are two major |
112 |
> projects, and parts of it are installable separately (client libs). |
113 |
|
114 |
Off-topic, but I'm really happy about MariaDB! I remember helping with |
115 |
a MariaDB developer meeting in the early days and I was very excited |
116 |
that most long-time developers decided to join Monty on MariaDB. Ever |
117 |
since, MySQL is irrelevant to me. But I do appreciate that people who |
118 |
are stuck with some Oracle support contract can still use it in Gentoo. |
119 |
|
120 |
|
121 |
> I trust (hope) that this will give you a small amount of insight into |
122 |
> what you're asking. |
123 |
|
124 |
I thought it was clear for a good number of mails that I'm /not/ asking |
125 |
to continue ensuring that openssl and libressl are interchangeable in |
126 |
Gentoo; |
127 |
|
128 |
I'm asking to ensure that libressl stays available /in some capacity/ even |
129 |
if that can only be as a special case, and it looks like that would |
130 |
require only very little upfront effort and zero recurring effort. |
131 |
|
132 |
|
133 |
Thanks a lot for your thoughtful response! I hope I could clarify some things. |
134 |
|
135 |
|
136 |
Kind regards |
137 |
|
138 |
//Peter |