[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