Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1991 - Support for link-level dependency tracking
Summary: Support for link-level dependency tracking
Status: RESOLVED LATER
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: x86 All
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 2031 6030 13663 15822 16245 16356 17515 17653 18362 19615 19775 19887 20540 20697 22832 32690 34979 90746 138799 343541 345755 (view as bug list)
Depends on: 5872 force-rebuild
Blocks: 155723 2765 12210 14456 29634
  Show dependency tree
 
Reported: 2002-04-21 19:08 UTC by qube99
Modified: 2011-10-30 22:37 UTC (History)
27 users (show)

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 qube99 2002-04-21 19:08:20 UTC
When updating a dependency, allow for a user to also recompile all children so
they work. For example, when updating libpng, also recompile galeon, kdm, etc.
Comment 1 Tom Ribbens 2002-08-04 12:21:59 UTC
This is a dupe of bug 2031
Comment 2 SpanKY gentoo-dev 2002-08-27 11:18:04 UTC
*** Bug 2031 has been marked as a duplicate of this bug. ***
Comment 3 SpanKY gentoo-dev 2002-08-27 11:19:26 UTC
*** Bug 6030 has been marked as a duplicate of this bug. ***
Comment 4 SpanKY gentoo-dev 2003-02-24 15:45:41 UTC
*** Bug 16245 has been marked as a duplicate of this bug. ***
Comment 5 SpanKY gentoo-dev 2003-02-25 15:09:53 UTC
*** Bug 16356 has been marked as a duplicate of this bug. ***
Comment 6 Martin Holzer (RETIRED) gentoo-dev 2003-03-17 13:57:05 UTC
*** Bug 17653 has been marked as a duplicate of this bug. ***
Comment 7 Martin Holzer (RETIRED) gentoo-dev 2003-04-21 19:06:08 UTC
*** Bug 19615 has been marked as a duplicate of this bug. ***
Comment 8 Martin Holzer (RETIRED) gentoo-dev 2003-04-22 06:32:57 UTC
*** Bug 15822 has been marked as a duplicate of this bug. ***
Comment 9 Martin Holzer (RETIRED) gentoo-dev 2003-04-24 05:38:10 UTC
*** Bug 19775 has been marked as a duplicate of this bug. ***
Comment 10 Martin Holzer (RETIRED) gentoo-dev 2003-04-24 14:39:17 UTC
*** Bug 19887 has been marked as a duplicate of this bug. ***
Comment 11 Martin Holzer (RETIRED) gentoo-dev 2003-05-09 12:51:42 UTC
*** Bug 20697 has been marked as a duplicate of this bug. ***
Comment 12 Martin Holzer (RETIRED) gentoo-dev 2003-05-09 15:34:19 UTC
*** Bug 20540 has been marked as a duplicate of this bug. ***
Comment 13 Martin Holzer (RETIRED) gentoo-dev 2003-06-04 16:35:14 UTC
*** Bug 17515 has been marked as a duplicate of this bug. ***
Comment 14 Martin Holzer (RETIRED) gentoo-dev 2003-06-25 15:25:26 UTC
*** Bug 13663 has been marked as a duplicate of this bug. ***
Comment 15 Martin Holzer (RETIRED) gentoo-dev 2003-08-06 00:50:05 UTC
*** Bug 22832 has been marked as a duplicate of this bug. ***
Comment 16 Martin Holzer (RETIRED) gentoo-dev 2003-08-06 00:50:17 UTC
*** Bug 25919 has been marked as a duplicate of this bug. ***
Comment 17 Shahar Goldin 2003-10-23 21:06:58 UTC
Doesn't `emerge -uD` do this?
Comment 18 Torgeir Hansen 2003-10-24 02:13:08 UTC
Not really, -D checks for updates in the dependencies of the ebuild or class
you are updating, e.g. if there is an gd-update and I've emerged mrtg, then
-uD mrtg should update gd for me.

However.

If I have emerged mysqltool (whatever that is;), or another app that was
installed while MySQL-3.x was installed that links to libmysqlclient.so.10
- and I update to MySQL-4 this will be a problem since MySQL-4 has updated
the version of it's client library, and uses libmysqlclient.so.12 (I believe
it was). At this point mysqltool (or whatever turns you on) will be broken,
as it tries to load a shared library that is no longer available.
This is also true for applications that statically link libraries, what if
someone linked statically the mysql client library; upgraded MySQL to a more
recent version that has changed the way the client and server talks? Same
issue - problems; only that it will be harder to detect. (this is especially
true for system USERS that don't even know what a library is, they just expect
things to work)




Comment 19 Martin Holzer (RETIRED) gentoo-dev 2003-11-30 06:20:55 UTC
*** Bug 32690 has been marked as a duplicate of this bug. ***
Comment 20 Martin Holzer (RETIRED) gentoo-dev 2003-12-04 03:34:07 UTC
*** Bug 34979 has been marked as a duplicate of this bug. ***
Comment 21 Martin Holzer (RETIRED) gentoo-dev 2004-01-03 04:16:06 UTC
see mad and madplay
portage doesn't update the dependencies when ~ is in use
Comment 22 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2004-02-14 20:46:49 UTC
Just ran into this again with mplayer and DirectFB, and here's my idea for a solution:

When a package is merged, a file is created listing what specific package and version fullfilled a dependancy. This file could be stored in /var/db/pkg with the other metadata that is there. When a package is upgraded (possibly with a special option to check for reverse dependancies) it grep's those files for the package that it is upgrading and add's those to the list of packages to be emerged.

Caveat: It may take quite some time to grep through the necessary files, especially if there are many packages installed. I'm not sure how to optimize this. (though this may not be as much of a problem as I thought, I just ran `grep 'DirectFB' /var/db/pkg/*/*/DEPEND` and it only took a few seconds, and I'm on a very low end machine. `ls /var/db/pkg/*/*/DEPEND | wc` comes up with a count of 385 files)

Unrelated: This could also lead to a solution to the binary package dependency problem where the binary package links against one version of a library, but another version of the library is installed, and portage sees the new version as fulfilling the dependency. (see http://thread.gmane.org/gmane.linux.gentoo.devel/15665)
Comment 23 klavs klavsen 2004-02-15 01:13:55 UTC
I've come up with a suggestion that would solve this problem - so "children" keep working after the upgrade - and doesn't have to be recompiled before they work - meaning you can still work at the computer, and let the recompiling just happen in the background - or even shutdown the computer and start again - and everything will still work - and recompilation can just continue.

see:
http://vsen.dk/files/GLEP-Making_updates_never_break_dependencies.txt

I'd be happy for constructive comments on this :)
Comment 24 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2004-03-20 06:22:24 UTC
After much debate and hashing of issues via private e-mail back and forth with Klavs Klavsen, I believe I have a working proof-of-concept patch to portage that implements reverse dependencies.

The patch plus associated tools and documentation can be downloaded from:
http://insaneone.com/releases/revdep/portage-2.0.50-r1-revdep1.tar.bz2

MD5 Sum and GPG Signature are available from the same location as well.

Hopefully this fix will get us through until a proper solution can be designed in portage-ng.
Comment 25 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2004-03-20 07:52:34 UTC
Klavs was quick to find a bug in the patch (it was calculating the reverse deps of the to-be-installed package version instead of the already installed version) and I have since fixed it.

New tarball:
http://insaneone.com/releases/revdep/portage-2.0.50-r1-revdep2.tar.bz2
Comment 26 Patrick Dawson (RETIRED) gentoo-dev 2004-08-09 23:22:55 UTC
*** Bug 57258 has been marked as a duplicate of this bug. ***
Comment 27 Brian Harring (RETIRED) gentoo-dev 2005-02-27 21:30:12 UTC
Jason, any thoughts on this?  The CDEPEND/bin_compat thing should address the mysql horkages...
Comment 28 Robert Forsman 2005-05-18 11:04:25 UTC
*** Bug 90746 has been marked as a duplicate of this bug. ***
Comment 29 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:24:51 UTC
Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 
Comment 30 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-07-30 13:14:47 UTC
*** Bug 18362 has been marked as a duplicate of this bug. ***
Comment 31 Jason Stubbs (RETIRED) gentoo-dev 2005-07-30 21:21:49 UTC
*** Bug 18362 has been marked as a duplicate of this bug. ***
Comment 32 Zac Medico gentoo-dev 2006-07-01 20:40:33 UTC
*** Bug 138799 has been marked as a duplicate of this bug. ***
Comment 33 Jeroen Roovers (RETIRED) gentoo-dev 2010-11-01 06:21:28 UTC
*** Bug 343541 has been marked as a duplicate of this bug. ***
Comment 34 Jeroen Roovers (RETIRED) gentoo-dev 2010-11-17 15:33:42 UTC
*** Bug 345755 has been marked as a duplicate of this bug. ***
Comment 35 John L. Poole 2010-11-17 16:37:28 UTC
The problem of tracking children and grandchildren seems to me a database component is warranted.  (I work for Oracle and am not expressing any opinion on its behalf, these opinions are solely my own.)  I read Klars proposal (Comment #23) and thought tracking the builds and their dependencies and having a tools to reconcile the file system with the user's database would make the resolution of determining problems ahead of time a snap.

Of course, this would require introducing an additional step to register file and libraries in the database at build time.  The goal here is to have the computer's state maintained in a database that mirrors the file system, then ebuilds could query for possible problems and proceed accordingly.

Is the concept of incorporating a database into portage an anathema or already been considered?
Comment 36 Zac Medico gentoo-dev 2010-11-17 17:16:24 UTC
(In reply to comment #35)
> Is the concept of incorporating a database into portage an anathema or already
> been considered?

Well, we already have /var/db/pkg/*/*/NEEDED.ELF.2, which is used by portage-2.2 to implement FEATURES=preserve-libs and emerge --depclean-lib-check.

However, long-term, I think that we should replace the NEEDED.ELF.2 approach with an abi-slot dependency approach as discussed in bug 192319. The advantage of abi-slot dependencies is that the information is encoded into the unbuilt ebuilds, allowing for more completeness dependency calculations.