[gentoo-dev] Imprecise dependency specification causing problems with cave

[gentoo-dev] Imprecise dependency specification causing problems with cave

[Taahir Ahmed]

I've recently switched to using cave (part of the paludis project) as the 
package manager for my system.

It's more conservative than emerge in some instances, specifically when it 
comes to bare dependencies (DEPENDS or RDEPENDS that are un-versioned).  For 
example:

* The ebuild for virtual/linux-sources has as part of its RDEPEND "sys-
kernel/gentoo-sources".  I have several versions of "sys-kernel/gentoo-
sources" installed on my system, and cave will not let me uninstall the older 
ones.  Because the dependency is unversioned, cave's point of view is that it 
can't be sure that it doesn't actually depend on some specific features of the 
currently-installed atoms.

* The ebuild for "app-office/calligra" has "media-libs/openexr" as a 
conditional RDEPEND.  The latest version of "media-libs/openexr" is in a 
subslot "0/20", so cave wants to keep the older version to satisfy calligra's 
dependencies.

In both of these cases, after reading the ebuild to verify that nothing should 
break beyond being fixed by "cave fix-linkage" (analogous to "revdep-
rebuild"), I can instruct cave to ignore the conflicts it perceives and 
proceed.

When I come across such a situation, should I submit a patch for the ebuild in 
question to specify the acceptable slots and versions for the DEPENDS and 
RDEPENDS (both of my examples are EAPI=5, so the slot specifier := can be 
used)?  Or are these ebuilds correct and cave in the wrong?

It should be noted that the first position (that the dependencies specified in 
the ebuilds are not sufficient) is the position of cave's developers.  I tend 
to agree -- How is cave to know that there hasn't been a brekaing change in a 
library's API?

Thanks,

Taahir Ahmed

Re: [gentoo-dev] Imprecise dependency specification causing problems with cave

[Rich Freeman]

On Sun, May 12, 2013 at 9:29 PM, Taahir Ahmed <ahmedtd@tamu.edu> wrote:
> It should be noted that the first position (that the dependencies specified in
> the ebuilds are not sufficient) is the position of cave's developers.  I tend
> to agree -- How is cave to know that there hasn't been a brekaing change in a
> library's API?

If a dependency does not specify a version then any version of that
package must be able to satisfy the dependency.  That certainly sounds
like it is the case with the examples you cited.

That doesn't mean that you can simply replace foo-1 with foo-2 and not
have stuff break - it might require some rebuilding.  Certainly a
package with a := slot-operator dependency should be considered likely
to break if the dependency changes subslots.

How exactly cave handles these situations is up to its maintainers.
I'd think that they should gracefully handle subslot changes since
EAPI5 finally has enough information to take care of this (more or
less).  For pre-EAPI5 packages I could see why they'd keep the old
versions around to avoid breaking linkage, but that is an
implementation decision.  Keep in mind that even if the dependency is
EAPI5 it might have reverse dependencies that do not specify subslot
operator dependencies in which case a package manager can't be sure
how to handle things.  If you have even a single package which does
not give a subslot operator then the package manager can't be sure
what will happen if the old version is removed.

The behavior of emerge is to rebuild if there is a subslot operator
dependency, keep the old lib around while unmerging it if
preserve-libs is enabled until it is no longer referenced, or just
break stuff if neither of those is the case.  That certainly isn't the
only way to do things.

Rich