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
