| 1 |
On 09/29/2015 05:31 PM, Alexis Ballier wrote: |
| 2 |
> On Sat, 19 Sep 2015 23:04:14 +0200 |
| 3 |
> hasufell <hasufell@g.o> wrote: |
| 4 |
> |
| 5 |
>> 2. slowly start migrating those ~550 packages with "libressl" USE flag |
| 6 |
>> which is similar to gnutls USE flag. |
| 7 |
>> There will be no virtual, because those don't give sufficient control |
| 8 |
>> (libressl and openssl are not ABI compatible). |
| 9 |
> |
| 10 |
> If API compatibility is guaranteed, a virtual makes more sense than a |
| 11 |
> useflag. However, even with this assumption, it's not possible these |
| 12 |
> days, because we need to: |
| 13 |
> - Fix || ( a:= b:= ) deps handling in package managers (hey dynamic |
| 14 |
> deps :) ) |
| 15 |
> - Create transitive := deps (useful for other things than virtuals, hey |
| 16 |
> ocaml & haskell). |
| 17 |
> |
| 18 |
> |
| 19 |
> So yeah, because of lack of better solution this seems to be the best |
| 20 |
> method so far. |
| 21 |
> |
| 22 |
|
| 23 |
Even if we fix the problem of SUBSLOTs in virtuals, we still have the |
| 24 |
situation that makes for example virtual/ffmpeg insufficient for a lot |
| 25 |
of use cases: even the API is not always strictly compatible, so ebuild |
| 26 |
writers sometimes need more fine-grained control over the version strings. |
| 27 |
|
| 28 |
This problem is very likely to arise with libressl as well. They want to |
| 29 |
be API compatible, but: |
| 30 |
* sometimes drop functions that they think have security flaws that |
| 31 |
can't be reasonably fixed |
| 32 |
* have their own set of functions on top of the openssl API |
| 33 |
|
| 34 |
Because of the last point, it is also possible that packages start to |
| 35 |
rely on libressl-specific API and not just on the common part. |
| 36 |
|
| 37 |
So a virtual doesn't seem to make sense, no matter how you look at it, IMO. |
Archives