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