El mié, 06-06-2012 a las 19:33 +0100, Ciaran McCreesh escribió: > On Wed, 06 Jun 2012 20:30:52 +0200 > Pacho Ramos <pa...@gentoo.org> wrote: > > > > Also, how could this be handled in dbus-glib side? I mean, would > > > > we need to update dbus-glib update from RDEPENDing on glib:2.30 to > > > > glib:2.32? :O > > > > > > Noooooo. You'd use := dependencies, possibly with a >= constraint. > > > > But, what would occur if we have three slots (for example gtk+), and > > app needs to RDEPEND on slot 2? How would we set it to use every 2.* > > SLOT and not >=2? > > Then you'd need range dependencies. > > > Also, what is the reason to try to skip "ABI_SLOT" way? > > No-one's ever implemented it, or knows how it works, or knows what > exactly it's supposed to do. The only advantage ABI_SLOT has is that we > don't know what its limitations are, other than that it doesn't > solve any new problems (although it might slightly simplify certain > specific cases, maybe).
Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. In summary: we would still need to use a "top layer" SLOT for packages really being able to be parallel installed and those that need to be parallel installable because reverse dependencies doesn't work with latest version (like glib, libgda, gtk+...). ABI_SLOT would be more "internal" to allow portage managers to know that abi changed and reverse dependencies would need a later rebuild.
signature.asc
Description: This is a digitally signed message part
