Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 387727 - binpkgs: tracking SONAME dependencies
Summary: binpkgs: tracking SONAME dependencies
Status: RESOLVED DUPLICATE of bug 192319
Alias: None
Product: Portage Development
Classification: Unclassified
Component: .tbz2 support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 19:38 UTC by Victor Mataré
Modified: 2011-12-02 15:31 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Mataré 2011-10-19 19:38:38 UTC
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
Comment 1 SpanKY gentoo-dev 2011-11-29 06:06:48 UTC
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.
Comment 2 Victor Mataré 2011-11-29 09:19:56 UTC
(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.
Comment 3 SpanKY gentoo-dev 2011-11-30 19:39:59 UTC
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.
Comment 4 Zac Medico gentoo-dev 2011-11-30 20:16:50 UTC
(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.
Comment 5 Victor Mataré 2011-12-01 21:21:32 UTC
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 ;-)
Comment 6 Zac Medico gentoo-dev 2011-12-01 21:40:27 UTC
(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.
Comment 7 Victor Mataré 2011-12-02 15:31:55 UTC
ok, then this can be considered another dupe of #192319. sorry.

*** This bug has been marked as a duplicate of bug 192319 ***