| Summary: | merging should not exit as soon as one package merge fails | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | nth <y.lesaint> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | amittp, bugs.gentoo.org, bugs.gentoo.org, burcheri.massimo+bugs-gentoo, cchris0396, daevid, f.fracassi, fasaxc, gentoo-bugs, gentoo, khanreaper, lassahn, mark.morschhaeuser, matthias.foerste, mholzer, miguel.filipe, pacho, paulpach, richard, robert.cole, wes |
| Priority: | High | Keywords: | InVCS |
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 14078 | ||
| Bug Blocks: | 155723, 184128, 216231 | ||
| Attachments: |
patch fix + enhancement
stable for me broken patch still won't install circular dependencies that exists between glibc and binutils portage-2.0.46-r5-patch circular dependencies is working ? |
||
*** Bug 12163 has been marked as a duplicate of this bug. *** Created attachment 6781 [details, diff] patch fix + enhancement new --retry and --firstfail options, verbose now show currently merging packages See http://perso.wanadoo.fr/y.lesaint/gnu/portage/portage-2.0.46-r4.patch for any consideration about this patch. Created attachment 6817 [details, diff] stable for me Patch seems like stable to me, but i do not use every portage functionnality. I will not touch it unless an error is reported. If portage grows, i may adapt it to fit portage version. Check http://perso.wanadoo.fr/y.lesaint/ Created attachment 6858 [details, diff] broken patch The patch is broken, it will not let you install circular dependencies that would have been installed without it. I have noticed it with sys-devel/binutils-2.13.90.0.16-r1 and sys-libs/glibc-2.3.1-r3 both referencing each other ... standard portage allows installation and patched portage does not ... The broken patch and i are still available at http://perso.wanadoo.fr/y.lesaint/gnu/portage/ and y.lesaint@free.fr Does this check dependencies for each ebuild? If I try to merge a package but one of its dependencies fails, then the package shouldn't be merged (I would still want the other dependencies to be installed if possible though). Created attachment 6859 [details, diff]
still won't install circular dependencies that exists between glibc and binutils
Very short answer:
Yes it does
Long answer:
All packages that could be installed with their dependencies satisfied are
installed
Here is how --retry works (briefly) :
--retry makes passes :
each pass walk through the would-be installed packages
each package, if not already installed, is a `root package', is tried to
be merged
if the merge successes, then the package is removed from the list of
packages to install
if some packages were merged successfully, then another pass begins
What are the `roots packages' ?
see allroots(), in portage.py, ( class depgraph i think )
a root package is a package that all packages it depends on are installed.
But still, circular dependencie between glibc and binutils is really a pain
in the ass ...
Created attachment 6860 [details, diff]
portage-2.0.46-r5-patch
Patch for portage-2.0.46-r5-patch is out !
And yes, "nice -n 5 emerge --retry --verbose -u world 2>&1 | tee $HOME/log"
is sooo cool :)p
Created attachment 6861 [details, diff]
circular dependencies is working ?
I do not know why, i think it has failed before, but i have rsync()ed, and now
it works ...
By the way, if someone knows how i could tell me how to send message without
any attachment, it would be fair
*** Bug 12362 has been marked as a duplicate of this bug. *** *** Bug 13477 has been marked as a duplicate of this bug. *** *** Bug 13575 has been marked as a duplicate of this bug. *** *** Bug 13627 has been marked as a duplicate of this bug. *** *** Bug 18141 has been marked as a duplicate of this bug. *** *** Bug 40565 has been marked as a duplicate of this bug. *** Workaround: To emulate the make -k functionality you can do: emerge -kbvu world emerge --resume --skipfirst -kubv world emerge --resume --skipfirst -kubv world emerge --resume --skipfirst -kubv world emerge --resume --skipfirst -kubv world ... It is not pretty but seems to work *** Bug 41793 has been marked as a duplicate of this bug. *** *** Bug 85937 has been marked as a duplicate of this bug. *** *** Bug 99801 has been marked as a duplicate of this bug. *** *** Bug 20779 has been marked as a duplicate of this bug. *** Pardon my asking, for I do not intend to spam, but are #12768 and #68944 duplicate bugs to an extent? *** Bug 68944 has been marked as a duplicate of this bug. *** *** Bug 112162 has been marked as a duplicate of this bug. *** This is a pretty popular one (understandably)... it doesn't take 3 years to write a few lines of code, does it? (In reply to comment #23) > This is a pretty popular one (understandably)... it doesn't take 3 years to > write a few lines of code, does it? If it were as simple as "a few lines of code" then this would be done by now. It's being worked on ( hence it still being open and not RESOLVED LATER ), so either submit patches or wait patiently for someone to write it. It's not a problem for me anymore, but it's a little strange to still be getting emails about it when I can't imagine what kind of architecture would make this take more than a day for someone who knows the system... I'm sure they have lots of other things that could benefit from their time, but since this bug was reported most significant upgrades that I tried to do failed because of it; the only way to get close to completing them is to upgrade individual packages until only the broken ones and their dependencies remain. But maybe that's not such a bad thing, considering what usually happens when you do manage to upgrade 30 to 50 packages all at once :) *** Bug 114351 has been marked as a duplicate of this bug. *** *** Bug 127199 has been marked as a duplicate of this bug. *** *** Bug 154336 has been marked as a duplicate of this bug. *** *** Bug 153763 has been marked as a duplicate of this bug. *** *** Bug 199927 has been marked as a duplicate of this bug. *** I've added a new --keep-going option. This uses some of the same code that's used for emerge --resume. When a failure occurs, dependencies are recalculated for remaining packages and any with unsatisfied dependencies are automatically dropped. (In reply to comment #31) > I've added a new --keep-going option. This uses some of the same code that's > used for emerge --resume. When a failure occurs, dependencies are recalculated > for remaining packages and any with unsatisfied dependencies are automatically > dropped. > Thanks a lot :-D This is fixed in 2.2_rc2. Thanks a lot for your great work, seems that "Release Notes" for portage-2.2 will be huge :-D |
Here is my concern, when i update my gentoo (emerge -u world) or install some new packages, there always are some packages that do not merge `out of the box'. And when this happens (means always), emerge() does not go on merging the other packages (those that could be merged). So i have added --retry option to emerge : - Compile all packages before exiting, even if some do fail. - Retry to compile failed packages if some packages have been built successfully (it works sometime). - Still take care of dependencies and does not break previous fonctionnalities. I have made a patch for sys-apps/portage-2.0.46-r4, you can apply it from portage main directory (the one containing bin/, pym/, ...) with `patch -p1'. The patch is here --> http://perso.wanadoo.fr/y.lesaint/gnu/portage/portage-2.0.46-r4.patch It is an ascii file, not an html one. The patch worked for me, i have only tried updating and merging new packages. But i think it should not affect other functionnalities. Whatever you decide, please : - I am available at y.lesaint@free.fr - email me about your decision - forgive my bad english Truly yours, happy new year ! Nth.