On Mon, 2022-02-21 at 00:12 +0200, j...@clusters.gr wrote:
> Pardon me, but how would using --nodeps be a wise choice to rebuild
> your @world?
Straightaway, it isn't. But if you've already computed the list of
packages to be emerged, and the order in which to emerge them, then
emerging those one-at-a-time with --nodeps shouldn't cause any problems
because you'll be emerging the dependencies before the packages that
need them.
We're brainstorming a workaround for two related portage annoyances:
1. Sometimes, if you try to upgrade too few packages, portage can't
figure out what to do because the depgraph isn't big enough for
it to see "the big picture." Like if there's a perl upgrade
requiring --backtrack=200 or something like that.
2. Sometimes, if you try to upgrade too many packages, portage can't
figure out what to do because the dependency graph gets too
complicated. Often the way around this is to "emerge -1" things
until the remaining package list is small enough that portage can
deduce what to do.
To solve (1), you want to use "emerge -uDN --backtrack=<a lot> @world".
But then this puts you in situation (2). In that scenario, it would be
really nice if there was a way to tell portage to "just start doing
it," so that you don't have to sit there and manually "emerge -1"
things for an hour. But then to avoid falling back into situation (1),
and to speed the process up, it would have to proceed as if --nodeps
was given.
Depending on what fails, you could still get into trouble by upgrading
a package whose dependencies have failed to upgrade. But after enough
wasted hours, I stop caring about that. Thus the semi-humorous
suggestion of "emerge --i-dont-care".
