1 |
Rich Freeman <rich0@g.o> writes: |
2 |
|
3 |
> A new slot of a package (which doesn't exist today) may or may not |
4 |
> work with any ebuild in the system. Should it be considered a best |
5 |
> practice then to specify || deps with all slots that are known to work |
6 |
> in the tree? Or should we just trust to luck and consider it |
7 |
> acceptable for maintainers to add new slots of commonly-used libs and |
8 |
> users and downstream maintainers can deal with the resulting breakage? |
9 |
> |
10 |
> Library maintainers don't seem to like dealing with that, so they just |
11 |
> stick new slots in an entirely new package, and then we end up with |
12 |
> all the || dependencies anyway and we make no use of the nice slot |
13 |
> syntax because it is prone to breakage. |
14 |
> |
15 |
> It seems like the current way we handle slots for dependencies works |
16 |
> just fine until somebody actually tries to introduce a new slot for a |
17 |
> package, and then a whole pile of assumptions comes crashing down. |
18 |
|
19 |
How about defining a QA workflow for introducing a new slot of a |
20 |
library, such as "mask it and open a tracker bug until every individual |
21 |
reverse dependencies are checked"? |
22 |
|
23 |
Benda |