What is --backtrack

[josephg]

on a recent issue i raised on this forum, --backtrack=30 was recommended to me, and it resolved my problem by recompiling fifty-six packages instead of the initial two.

i have never needed to use --backtrack before. i can't seem to find much information, apart from one sentence in the man page which i don't completely understand.

[audiodef]

It backtracks through the dependency tree to the level specified by the provided integer. When I do my monthly world updates, I use an insane number like 1000 to make sure nothing is missing or broken.
_________________
decibel Linux: https://decibellinux.org
Github: https://github.com/Gentoo-Music-and-Audio-Technology
Facebook: https://www.facebook.com/decibellinux
Discord: https://discord.gg/73XV24dNPN

[josephg]

[NeddySeagoon]

josephg,

When dependency resolution comes to dead end, portage has two choices
[*]tell you it failed and provide a sometimes less than helpful error message
[*]go back some branches in the dependency tree and look for a different route

The default is --backtrack=3. The higher the setting, the further back in the dependency tree portage is allowed to go to try to find a solution.
Notice the 'allowed to go'.
If the default --backtrack=3 would of worked --backtrack=30 should produce the same solution in the same amount of time. (I've not tested that)
When --backtrack=3 fails and --backtrack=30 works, portage has gone back more that three levels in the dependency tree to reach a solution but you don't know how far, maybe only 4?

The downside to large --backtrack= settings is that it takes longer to get to the error message when there is no solution to the dependency graph.

Testing --backtrack= for 0,1 and 2 is left as an exercise to the reader.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[josephg]

[NeddySeagoon]

josephg,

The difference should only be apparent when the default --backtrack=3 results in a conflict error message and --backtrack>3 finds a solution.
If backtrack=0 works, portage got it right first time and no backtracking was required.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[kornhs4]

The difference is the following: Assume there is actually no solution to your current set of package dependencies. If you set --backtrack=N for a very high N then you force it to look for it, minutes, hours, years, for the age of the universe, until it finds that there is no solution. (The computational problem considered here is NP hard, so the age of the universe is no exaggeration.)

Instead you may want to leave N at its default (which is 10 according to `man emerge` here). Then it tells you after some "reasonable" amount of time that it could not fulfill your wishes and tells you about the conflict. (Which is often not easy to read for a human.) Anyhow, you as a human may (or may not) easily see what the "real" problem is as a package is mentioned that is now hard masked you do not care about anymore, so uninstall it. And suddenly all works out very quickly.
_________________
_________________
Life would be easier
if i had the source code

[lburrow]

Sorry to wake such an old thread but this has to be bad information and I had to say something.

OK, Here's my routine.

I use an alias for my updates.
alias eu='emerge -u -D --keep-going --backtrack=100 --newuse --with-bdeps y world'

My routine is:
• open a screen session
• eix-sync
• eu -p
• eu
• dispatch-conf
• emerge --depclean -p
• emerge --depclean
• emerge @preserved-rebuild -p
• emerge @preserved-rebuild
• revdep-rebuild -p
• revdep-rebuild

I do this almost daily.

Ok. So that alias is something I have built up over the years in a quest to get a most trouble-free, consistent and complete update. This alias has worked pretty well for me but I can't say I entirely understand it, with that --backtrack= being one of the parts I least understand.

I have RTFM but that just leaves me with the same conclusions others have responded here, none of which match my experience at all!

So, that alias... I added the --backtrack, and kept raising the number until I stopped at 100 because it seems to give me fewer blockers this way. It is slower, but I don't care. It's usually running in the background while I am working but also I can walk away.

So far that matches the explanations others have given right?

But every once in a while (I'm talking several months apart) there is something tricky and it comes up with blockers anyway. Increasing that number above 100 has never helped. But.. sometimes just running "emerge -u world" makes the problem just go away. It emerges some stuff and the next time I do "eu" it's back to just working.

If it worked like described above there shouldn't be any situations where running with --backtrack set to 100 does not resolve the problem but running without --backtrack set does.

Today I have an even weirder situation. For the last week or so "eu" has resulted in a ton of blockers. For some reason updating qtgui and qtcore were blocked by a bunch of qt apps. I want to say I was stuck on 5.15.9 although 5.15.10 was available.

Anyway, the really weird thing was all those apps that supposedly were blockers either only required qt be >=5 or had their own updates also available that would have resolved the conflict. This made no sense to me.

So.. I ran "emerge -u world". Nothing! It didn't even find that there was anything to do at all! But finally, shooting in the dark I tried "emerge -u --backtrack=10 world". Now it seems to be emerging all that qt stuff. It does nothing at the default setting, breaks at 100 but works at 10 (which one person thought WAS the default setting). I'm currently happy to be building qtwebengine, 48 of 59 but more convinced than ever that this does not follow any sort of logic.

Then there is that emerge @preserved-rebuild step.

It used to be there were almost always packages to emerge at that step. Now it seems to be much more rare although it does happen. So I don't get that one either. It seems to be packages that were not upgraded but need to be re-emerged because libraries they link to were? But during the "eu" or "emerge --upgrade" step I see all sorts of packages marked as being R-rebuilds, not U-updates. So why do some fall into this @preserved-rebuild while others just get rebuilt as part of the update step? Clearly emerge knows they need rebuilt in order to add them to the set. Is "leave my system broken" a valid wish that a user might have? Why isn't it just emerging them in the first place all on it's own???

The best I can tell from all this is that Gentoo is awesome, Portage is awesome but there is magic there. There are some things that just don't make sense to anyone at all and it is best just to know what to do even if not why. --backtrack is a feature that makes finding updates and dependencies slower but better, USUALLY more complete and with fewer conflicts. And usually being not-always one should be ready to try again without backtrack or with a lower backtrack. One can know to do this but understanding it.. nope, magic.

[sam_]

[sam_]

[sam_]