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.
This is a dupe of bug 2031
*** Bug 2031 has been marked as a duplicate of this bug. ***
*** Bug 6030 has been marked as a duplicate of this bug. ***
*** Bug 16245 has been marked as a duplicate of this bug. ***
*** Bug 16356 has been marked as a duplicate of this bug. ***
*** Bug 17653 has been marked as a duplicate of this bug. ***
*** Bug 19615 has been marked as a duplicate of this bug. ***
*** Bug 15822 has been marked as a duplicate of this bug. ***
*** Bug 19775 has been marked as a duplicate of this bug. ***
*** Bug 19887 has been marked as a duplicate of this bug. ***
*** Bug 20697 has been marked as a duplicate of this bug. ***
*** Bug 20540 has been marked as a duplicate of this bug. ***
*** Bug 17515 has been marked as a duplicate of this bug. ***
*** Bug 13663 has been marked as a duplicate of this bug. ***
*** Bug 22832 has been marked as a duplicate of this bug. ***
*** Bug 25919 has been marked as a duplicate of this bug. ***
Doesn't `emerge -uD` do this?
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)
*** Bug 32690 has been marked as a duplicate of this bug. ***
*** Bug 34979 has been marked as a duplicate of this bug. ***
see mad and madplay portage doesn't update the dependencies when ~ is in use
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)
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 :)
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.
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
*** Bug 57258 has been marked as a duplicate of this bug. ***
Jason, any thoughts on this? The CDEPEND/bin_compat thing should address the mysql horkages...
*** Bug 90746 has been marked as a duplicate of this bug. ***
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. ;)
*** Bug 18362 has been marked as a duplicate of this bug. ***
*** Bug 138799 has been marked as a duplicate of this bug. ***
*** Bug 343541 has been marked as a duplicate of this bug. ***
*** Bug 345755 has been marked as a duplicate of this bug. ***
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?
(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.