On 06/06/2012 02:48 AM, Pacho Ramos wrote: > El mié, 06-06-2012 a las 02:17 -0700, Zac Medico escribió: >> On 06/06/2012 01:28 AM, Pacho Ramos wrote: >>> El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: >>>> The "SLOT operator" dependencies that Ciaran has been advocating are >>>> very close to a good solution. However, if we want it to work with >>>> unslotted packages, then we need to introduce a separate ABI_SLOT >>>> variable as discussed here: >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 >>>> >>>> It's really no more difficult to do than "SLOT operator" dependencies, >>>> it's more flexible, and we can do it in EAPI 5. >>> >>> In that case, I obviously wouldn't have any problem with that approach >>> (it sound even better :)). Is there any place where I could get a bit >>> more documentation about how this "SLOT operator" way would work? For >>> example, how would work for rebuilding x11 drivers after updating xorg >>> or rebuilding gobject-introspection after major glib update... >> >> Whenever you have an ABI change, the developer doing the version bump >> needs to increment the SLOT (or ABI_SLOT if we use a separate variable) >> in the package. Packages that depend on the package with the ABI change >> (reverse dependencies) append a := operator to their dependency atoms, >> indicating that they are locked to the ABI of the SLOT that they are >> built against. The package manager translates the := operators into a >> dependencies on specific SLOTs at build time, so that when you update >> your system next time, it can use this information to trigger rebuilds >> automatically when necessary. > > That looks nice, only two notes: > - Looks like would be more sense on distinguish between "SLOT" and > ABI_SLOT, for example: > * dbus-glib would rdepend on glib:2 > * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" inside glib-2 > ebuild > * dbus-glib rdepending on glib:=2 would get rebuilt > If we would use "SLOT" for all the cases, how would we handle it? I > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds updated > to rdepend on every new slot? Or would package managers distinct between > "versions" inside the same SLOT variable?
For this situation, it seems like it's easier to have separate SLOT and ABI_SLOT entities. Maybe the dbus-glib dependency would be expressed as glib:2:= and the package manager would translate that to glib:2:2.32 at build time. So, the atom has separate SLOT and ABI_SLOT parts. > - What would occur with packages forced to use eapi0 due backwards > compat? We could probably deprecate eapis older than 5 to allow all the > tree be consistent with this rebuilds forcing, but no idea what to do > with system packages still needing to use eapi0 and maybe changing their > ABI too :/ All EAPIs have SLOT, so at least the reverse dependencies on these system packages would be able to use SLOT operator deps. It's also conceivable that ABI_SLOT support could be retroactively added to older EAPIs. Obviously, the SLOT operator := dependencies themselves can only be used in new EAPIs, so you won't be able to use them until you're willing to bump the EAPI of your package. -- Thanks, Zac
