| 1 |
>>>>> On Thu, 4 Jan 2018, Mike Gilbert wrote: |
| 2 |
|
| 3 |
> On Thu, Jan 4, 2018 at 5:23 AM, Pacho Ramos <pacho@g.o> wrote: |
| 4 |
>> I have seen this is only used by: |
| 5 |
>> app-arch/xz-utils |
| 6 |
>> dev-libs/gmp |
| 7 |
>> dev-libs/libpcre |
| 8 |
>> dev-libs/mpc |
| 9 |
>> dev-libs/mpfr |
| 10 |
>> net-nds/openldap |
| 11 |
>> sys-libs/gdbm |
| 12 |
>> sys-libs/ncurses |
| 13 |
>> sys-libs/readline |
| 14 |
>> sys-process/audit |
| 15 |
>> |
| 16 |
>> Maybe we could deprecate it and try to drop it in the future :/ |
| 17 |
|
| 18 |
> As Soap touched on earlier, this should probably not be |
| 19 |
> deprecated/removed until a solution compatible with Paludis and |
| 20 |
> pkgcore is implemented. |
| 21 |
|
| 22 |
> A couple of options for that: |
| 23 |
|
| 24 |
> 1. Add functionality similar to preserve-libs to these alternate |
| 25 |
> package managers. This is unlikely to happen. |
| 26 |
|
| 27 |
There may also be Portage users without preserve-libs in FEATURES. |
| 28 |
|
| 29 |
> 2. Slot the libraries so that the old versions may remain installed |
| 30 |
> in a PMS-compatible way. This is often a pain to actually implement. |
| 31 |
|
| 32 |
I don't think that this would fly. You'd have to split packages like |
| 33 |
xz-utils which install binaries, otherwise there would be collisions |
| 34 |
between slots. |
| 35 |
|
| 36 |
> If neither of these things happens, keeping the preserve_old_lib |
| 37 |
> calls in place is an ugly, but workable solution. |
| 38 |
|
| 39 |
+1 |
| 40 |
|
| 41 |
Also note that the eclass functions act as no-ops when they find |
| 42 |
preserve-libs in FEATURES. |
| 43 |
|
| 44 |
Ulrich |
Archives