Recently I have needed pass higher values to emerge for backtracking, that made me wonder if maybe would be better to default to a much higher value. I think that because, currently, people will try to update their systems, after a long run, it can fail asking people to try a higher value, then, they need to run emerge *again* and wait *again* for it to complete. Probably that people would have saved time running it with a higher value from start and, then, not needing to wait for emerge to fail and need to re-run it again Thanks
In my case, I tried 15, 30 and, finally, simply went with 100 and all went fine
I use a default of 9999 always, because, well, the CPU needs *something* to do while I'm reading email. Other people might on the other hand not take too kindly to this. Anyway, I don't want to change this based on one person's hunch/need. We should try to ask around. Maybe even ask on gentoo-user & report your findings here? I've CC'd Sebastian, as he's one of the most likely to have some keen insight for us.
I'd rather not change the default value. The problem is that even with the current default, I've seen emerge run for an hour, just to tell you that it can't figure it out. What really needs to happen is that we stop using backtracking at all, especially for slot operator rebuilds.
(In reply to Alexander Berntsen from comment #2) > I use a default of 9999 always, because, well, the CPU needs *something* to > do while I'm reading email. Other people might on the other hand not take > too kindly to this. > > Anyway, I don't want to change this based on one person's hunch/need. We > should try to ask around. Maybe even ask on gentoo-user & report your > findings here? > > I've CC'd Sebastian, as he's one of the most likely to have some keen > insight for us. Well, my suggestion of using "100" came at the time I needed to update from Gnome 2.32 to 3.8... later I saw the perl-cleaner issue and I thought would be interesting to choose a higher default value (at least until the backtracking is not needed in the future)
(In reply to Pacho Ramos from comment #4) > Well, my suggestion of using "100" came at the time I needed to update from > Gnome 2.32 to 3.8... later I saw the perl-cleaner issue and I thought would > be interesting to choose a higher default value (at least until the > backtracking is not needed in the future) GNOME update is a very special case. I asked around, and everyone agreed with Seb to one degree or another. The consensus seems to be that Portage takes too long as-is, and fails equally embarrassingly with a higher backtrack value. And as Seb said, backtrack shouldn't happen at all. He's working on a backtrack-less Portage branch, as far as I know. Maybe you could confirm and give us a short status update? I know you're busy these days though. I asked Sergei Trofimovich about this issue too, and he said, as I expected from him, that 0 is the best wrt error messages. I tend to agree with him as a developer when I'm doing e.g. Gentoo-Haskell or local overlay stuff. As a *user*, I prefer just 9999 and pray Portage works it out itself. (I CC'd Sergei, in case he feels I'm misrepresenting his opinion.) For now, I suggest we close this as WONTFIX, if that's OK with Seb.
gx86 uses tiny fraction of subslots yet. One of my systems has "only" 51 perl package, i'd expect --backtrack=60 to save me (in case i have only perl to upgrade). Another has 81. few has some patches to handle rebuilds nicer: https://github.com/few/fews-portage-branch/commits/no-backtracking-for-rebuilds I can't work on gentoo-haskell overlay without that branch, really. Overlay has ~1000 ebuilds (almost all with subslot deps). It's a nice emulation of near future of gentoo-x86 :] Some packages have 800 revdeps, like dev-haskell/text. For dev-haskell/text bump there is no sane backtracking value you can chose to solve it in acceptable time (I have all 800 installed). I'd say we already need to fix subslot backtracking Right Now, but i am biased :]
Yeah, improving the conflict handling to work with less backtracking as suggested in comment #6 is the only viable solution.
(In reply to Sebastian Luther (few) from comment #3) > The problem is that even with the current default, I've seen emerge run for > an hour, just to tell you that it can't figure it out. Right, this is precisely why I have filed bug 536926 to *decrease* the --backtrack default. > What really needs to happen is that we stop using backtracking at all, > especially for slot operator rebuilds. Yes, and from comment #6, I see that you've already started on this.
