Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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