| 1 |
On Thu, 4 Jan 2018 10:35:23 -0500 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> On Thu, Jan 4, 2018 at 5:23 AM, Pacho Ramos <pacho@g.o> wrote: |
| 5 |
> > I have seen this is only used by: |
| 6 |
> > app-arch/xz-utils |
| 7 |
> > dev-libs/gmp |
| 8 |
> > dev-libs/libpcre |
| 9 |
> > dev-libs/mpc |
| 10 |
> > dev-libs/mpfr |
| 11 |
> > net-nds/openldap |
| 12 |
> > sys-libs/gdbm |
| 13 |
> > sys-libs/ncurses |
| 14 |
> > sys-libs/readline |
| 15 |
> > sys-process/audit |
| 16 |
> > |
| 17 |
> > Maybe we could deprecate it and try to drop it in the future :/ |
| 18 |
> > |
| 19 |
> |
| 20 |
> As Soap touched on earlier, this should probably not be |
| 21 |
> deprecated/removed until a solution compatible with Paludis and |
| 22 |
> pkgcore is implemented. |
| 23 |
> |
| 24 |
> A couple of options for that: |
| 25 |
> |
| 26 |
> 1. Add functionality similar to preserve-libs to these alternate |
| 27 |
> package managers. This is unlikely to happen. |
| 28 |
|
| 29 |
IMHO having profiles mandate a preserve-libs behavior (and thus PMS |
| 30 |
define this) for a few select packages (the ones above) is the way to go |
| 31 |
here: preserve-libs is evil but really the least evil in this case. |
| 32 |
If you miss the warning from the eclass, you can very easily end up |
| 33 |
with binaries loading the two versions of the library; preserve-libs |
| 34 |
has the advantage that portage is very loud about this. |
Archives