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?
- 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 :/