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

[Rich Freeman]

On Sun, May 12, 2013 at 9:29 PM, Taahir Ahmed <ahmedtd@××××.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