1 |
On Sun, Dec 8, 2013 at 3:01 PM, Ulrich Mueller <ulm@g.o> wrote: |
2 |
> Our rules of slot/subslot dependencies and slot operators are just |
3 |
> complicated enough, so I really would dislike complicating them even |
4 |
> more by having an EAPI dependent default. In addition, from a package |
5 |
> manager view there is nothing special at all about slot 0, so there's |
6 |
> no reason to prefer it over other values. |
7 |
|
8 |
I can see that argument, but what then? What should be the best |
9 |
practice for a maintainer? |
10 |
|
11 |
A new slot of a package (which doesn't exist today) may or may not |
12 |
work with any ebuild in the system. Should it be considered a best |
13 |
practice then to specify || deps with all slots that are known to work |
14 |
in the tree? Or should we just trust to luck and consider it |
15 |
acceptable for maintainers to add new slots of commonly-used libs and |
16 |
users and downstream maintainers can deal with the resulting breakage? |
17 |
|
18 |
Library maintainers don't seem to like dealing with that, so they just |
19 |
stick new slots in an entirely new package, and then we end up with |
20 |
all the || dependencies anyway and we make no use of the nice slot |
21 |
syntax because it is prone to breakage. |
22 |
|
23 |
It seems like the current way we handle slots for dependencies works |
24 |
just fine until somebody actually tries to introduce a new slot for a |
25 |
package, and then a whole pile of assumptions comes crashing down. |
26 |
|
27 |
Rich |