| Summary: | portage-2.1.2.11 reverses merge order of dependencies | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Andrew Evans <gentoo> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | fellows |
| Priority: | High | Keywords: | InVCS, REGRESSION |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949, 188739, 189285 | ||
| Attachments: |
improve merge order for cases where installed packages have unsatisfied dependencies
give higher priority to dependencies on packages specified as arguments |
||
|
Description
Andrew Evans
2007-08-14 05:16:26 UTC
Created attachment 128016 [details, diff]
improve merge order for cases where installed packages have unsatisfied dependencies
Normally this type of thing doesn't happen since XML-Parser should already be installed if intltool is installed.
(In reply to comment #1) > Normally this type of thing doesn't happen since XML-Parser should already be > installed if intltool is installed. This happens all the time, when doing a rebuild because of library ABI breakage. forums.g.o is full of the hassles (expat, curl upgrade) of revdep-rebuild breaking because of Portage not getting the build order right. I went yesterday evening through all open bugs, because I thought the bug regarding getting the ordering of the to be (re-)built ebuilds right must be still open, but actually didn't found it... Should this patch fix these issues or is there more about it? Yes, I was bitten by the expat upgrade too. portage-2.1.2.9 correctly merges expat before the packages that require/link against it. portage-2.1.2.11 doesn't. (In reply to comment #2) > Should this patch fix these issues or is there more about it? This patch reverts it to behavior that 2.1.2.9 had. It's better, but not as good as can be. In order to make it really optimal, we need to make it aware of ABI breakage so that it knows when an installed package is unusable to satisfy a dependency. Right now, the user would have to unmerge the broken packages to prevent the resolver from treating them as satisfied depenedencies. (In reply to comment #4) > In order to make it really optimal, we need to make it aware of > ABI breakage so that it knows when an installed package is unusable to satisfy > a dependency. Right now, the user would have to unmerge the broken packages to > prevent the resolver from treating them as satisfied depenedencies. There're a lot of possible breaking rebuilds where libs do not matter at all, e.g. scripting langauges, java, etc.. To let revdep-rebuild not fail, what Portage should do is actually merging the dependencies in order of the tree the dependencies form and not as they're given on the command line. To fix the revdep-rebuild issues now, there is no need to have Portage be aware of the ABI breakage. For proper reverse dependency support (and getting rid of revdep-rebuild) a lot more is needed, but Portage still shouldn't care about any libs; The relevant data needs to be part of the ebuilds, as we can't rely on upstream developers to change their library major version number to reflect an ABI change. There have been violations of this good practice and there will be in future. Also, as already pointed out - and I'm prettsy sure you are aware of it - libraries are only part of the picture. To give you an example of what's the broken status now: On my box due to the expat upgrade I had to rebuild musicbrainz and tunepimp (which depends on muscbrainz). revdep-rebuild basically spit out "emerge --oneshot tunepimp musicbrainz" and of course tunepimp failed. The funny thing about it is that actually Portage does the wanted bits already under certain conditions (this is with v.2.1.3.5)... WRONG: emerge tunepimp musicbrainz -p These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/tunepimp-0.5.3 [ebuild R ] media-libs/musicbrainz-2.1.4 RIGHT: emerge tunepimp musicbrainz -pt These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild R ] media-libs/musicbrainz-2.1.4 [ebuild R ] media-libs/tunepimp-0.5.3 Funny is that Portage does --pretend --tree in corrent order, but actually trying to build with --tree, but without --pretend, the order is wrong again. If Portage would actually build in order as --pretend --tree output prints it, there would (given there are no bugs in it - and issues with circular dependencies aside) be no problem with revdep-rebuild. Ah, missed the "reversed" in the -pt output... (In reply to comment #5) > To give you an example of what's the broken status now: On my box due to the > expat upgrade I had to rebuild musicbrainz and tunepimp (which depends on > muscbrainz). revdep-rebuild basically spit out "emerge --oneshot tunepimp > musicbrainz" and of course tunepimp failed. Use the attached patch together with the --deep option and it should give you a pretty good order in most cases. I can probably make it a little better still without ABI awareness. I'll look into it. (In reply to comment #7) > Use the attached patch together with the --deep option and it should give you a > pretty good order in most cases. I can probably make it a little better still > without ABI awareness. I'll look into it. Well, it's only a minor annoyance for me, but when you look in the forums or even lookup the bug reports marked as duplicates with "expat" in the comments lately, you get an idea what sort of big problem this is for (parts of) our user base. So that you're having a look is very appreciated. :) Created attachment 128134 [details, diff]
give higher priority to dependencies on packages specified as arguments
This patch includes the previous one and it also gives higher priority to dependencies on packages that have been specified as arguments (such as those given by revdep-rebuild).
This patch is released in portage-2.1.3.6. I'm also going to do a 2.1.2.12 release with the same patch, but I probably will wait until tomorrow to release that. portage-2.1.2.12 has been released with this patch. Closing since 2.1.2.12 is stable on most archs now. |
