| 1 |
On Sun, 20 Sep 2015 07:49:24 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> On Sun, Sep 20, 2015 at 5:50 AM, Alexis Ballier <aballier@g.o> |
| 5 |
> wrote: |
| 6 |
> > |
| 7 |
> > Yes, that's what gnome team is doing with gtk2 vs gtk3; however, I'm |
| 8 |
> > not sure how much work it is. Only package I know of providing |
| 9 |
> > different slots depending on what it's built upon is webkit-gtk. |
| 10 |
> > |
| 11 |
> > I can't imagine every library using {open,libre}ssl provide two |
| 12 |
> > slots, two different libraries, two different pkg-config and the |
| 13 |
> > like files, etc. And every package using a library that uses a |
| 14 |
> > library that uses a library that uses {open,libre}ssl to have to |
| 15 |
> > chose what ssl library to use. |
| 16 |
> > |
| 17 |
> |
| 18 |
> I don't think the suggestion is to make it so that any package can be |
| 19 |
> built against either, though individual maintainers can support this. |
| 20 |
> |
| 21 |
> I think the suggestion is to make it so that the libraries themselves |
| 22 |
> can be installed side-by-side, so that packages can depend exclusively |
| 23 |
> on one or the other and not effectively block each other. |
| 24 |
|
| 25 |
I don't think so, and I explained why it doesn't work: Loading both of |
| 26 |
them in the same process screws things up. |
| 27 |
|
| 28 |
See: |
| 29 |
https://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour#gsc.tab=0 |
| 30 |
|
| 31 |
and replace changing major number by changing library name, it's the |
| 32 |
exact same deal, or worse since it is now "permanent". |
Archives