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