| 1 |
On Mon, Aug 5, 2013 at 11:00 AM, Michael Palimaka <kensington@g.o> wrote: |
| 2 |
> Even though the subslot is implicit, is that any reason to still use the |
| 3 |
> operator? We don't know what the maintainer's future intentions for the |
| 4 |
> subslot will be. |
| 5 |
> For example, we caused many useless rebuilds with poppler because dependants |
| 6 |
> added the subslot operator without consideration (many packages link only |
| 7 |
> against one of the stable interface libraries, rather than the main library |
| 8 |
> for which the subslot was intended). |
| 9 |
|
| 10 |
That seems more of an issue with the design of slot operators - any |
| 11 |
particular upgrade of a library package doesn't necessarily break ABI |
| 12 |
on all of the library files it installs. |
| 13 |
|
| 14 |
I suspect most maintainers would rather upgrade their package once to |
| 15 |
EAPI5 and not keep checking back every month to see if there is a new |
| 16 |
opportunity to add another slot operator dep. If maintainers don't |
| 17 |
add them up-front even with the deps don't support them, chances are |
| 18 |
they'll never add them. |
| 19 |
|
| 20 |
How often does this situation even come up? If 9/10 times the |
| 21 |
libraries are set up as maintainers expect them to be, it is probably |
| 22 |
better to deal with the odd unnecessary rebuild until somebody spots |
| 23 |
it, rather than going without support for slot operator deps. |
| 24 |
|
| 25 |
Rich |
Archives