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