On Thu, 9 Apr 2009 16:29:53 +0530 Nirbheek Chauhan <[email protected]> wrote:
> I think the current way is the most easily-supportable way for us. > Complex interdependencies b/w packages and slots => O(n^k) times bugs, > where k = no. of slots for a library. > > If we don't get all those bugs, it means people are running the latest > package and latest slot. So slot operators would be m00t in that case. I wouldn't be using slotdeps as actual slotdeps, more like ABI deps. Each slot would soft-block all other slots, so upgrades would be handled normally by portage. Only, all other packages could use slotdeps to be rebuilt when a new version of gtk-sharp is released. It would probably take a bit of eclass fudgery, but it could be made to work. Also, it would allow people to mix ~arch and arch for -sharp stuff. Which would be good. As I said, I would be using slot-deps as ABI-deps. I would find actual ABI deps to be vastly more useful since I wouldn't have to keep track of earlier slots to block. Imagine a world with no revdep-rebuild? /loki_val
