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