gcc-4.5.3-r1.ebuild says: RDEPEND=">=dev-libs/gmp-4.3.2" BUT: # ldd /usr/libexec/gcc/i686-pc-linux-gnu/4.5.3/cc1 ... libgmp.so.10 => not found ... And /usr/lib/libgmp.so.10 is only installed after upgrading to dev-libs/gmp-5.0.2. So that dep needs to be changed I guess? Reproducible: Always
there's no way you could link against libgmp.so.10 without it being installed at the point in time when cc1 was linked. so if you had gmp-5.x installed, built gcc, then downgraded to gmp-4.x, that's an error on your part.
(In reply to comment #1) > there's no way you could link against libgmp.so.10 without it being installed > at the point in time when cc1 was linked. so if you had gmp-5.x installed, > built gcc, then downgraded to gmp-4.x, that's an error on your part. Sorry for reverting the status, but I think it's a totally plausible use case if you're using binpkgs. Please don't expect a binpkg user to magically know he can't cancel the update process just because gcc has just been updated but gmp hasn't been done yet. RDEPEND is supposed to deal with that. Also the updates might fail for any other random reason before gmp gets updated.
that has nothing to do with gcc. you're describing a general problem with binpkgs. atm, it is expected that the person maintaining the binpkg repo keep all their packages in sync themselves. that means when ABI's change, they have to rebuild. not sure if we already have a bug open on the topic, but most likely isn't going to be "addressed" any time soon.
(In reply to comment #3) > atm, it is expected that the person maintaining the binpkg repo keep > all their packages in sync themselves. that means when ABI's change, they have > to rebuild. Right, and the emerge --rebuilt-binaries option will pull in those rebuilt packages on the client automatically. Also --rebuilt-binaries is enabled automatically when --deep is specified together with --usepkgonly or --getbinpkgonly . > not sure if we already have a bug open on the topic, but most likely isn't > going to be "addressed" any time soon. We should be able to use LinkageMapElf (used to implement preserve-libs) to check for providers of the needed sonames before pkg_preinst, and abort if an soname is missing.
OK sorry, I should have made the scenario a bit clearer. Everything is fine on the (In reply to comment #4) > (In reply to comment #3) > > atm, it is expected that the person maintaining the binpkg repo keep > > all their packages in sync themselves. that means when ABI's change, they have > > to rebuild. > > Right, and the emerge --rebuilt-binaries option will pull in those rebuilt > packages on the client automatically. Also --rebuilt-binaries is enabled > automatically when --deep is specified together with --usepkgonly or > --getbinpkgonly . ok, I think I understand. Sorry I haven't made myself clear from the beginning. Then what I'd like to have is just a bit more safety, i.e. reducing the risk of a broken system in case the binpkg update process is interrupted (for whatever reason) before those SONAME dependencies get updated. In general, I'd just like to have this stuff in the dependency graph so we end up with a safer installation sequence. Of course SONAME deps might introduce extra circular deps (right?), in which case they should be disregarded. Nonetheless, we might want to try hard to satisfy them even after emerge is interrupted for whatever reason, and also throw a prominent error message if we're left with a broken state. Thanks anyways for putting this in the right perspective ;-)
(In reply to comment #5) > In general, I'd just like > to have this stuff in the dependency graph so we end up with a safer > installation sequence. That's what bug 192319 is about. If you want to account for SONAME dependencies in the dependency graph, it makes sense for unbuilt ebuilds as well as binary packages, since an unbuilt ebuild can introduce an SONAME dependency issues just as much as a binary package can. For example, consider any update that requires rebuild of reverse dependencies due to SONAME change, such as libpng-1.4x to libpng-1.5.x upgrades.
ok, then this can be considered another dupe of #192319. sorry. *** This bug has been marked as a duplicate of bug 192319 ***
