1 |
Am Mi., 3. Nov. 2021 um 23:15 Uhr schrieb Joshua Kinard <kumba@g.o>: |
2 |
> |
3 |
> On 11/3/2021 11:03, Thomas Deutschmann wrote: |
4 |
> > Hi, |
5 |
> > |
6 |
> > it is currently not possible to smoothly run a world upgrade on a 4 |
7 |
> > months old system which doesn't even have a complicated package list: |
8 |
> |
9 |
> [snip] |
10 |
> |
11 |
> > This is not about finding solution to upgrade the system (in this case |
12 |
> > it was enough to force PYTHON_TARGETS=python3_8 for portage). This is |
13 |
> > about raising awareness that Gentoo is a rolling distribution and that |
14 |
> > we guarantee users to be able to upgrade their system when they do world |
15 |
> > upgrades just once a year (remember: in my case the last world upgrade |
16 |
> > is just 4 months old!). If they cannot upgrade their system without |
17 |
> > manual intervention, we failed to do our job. |
18 |
> > |
19 |
> > Situations like this will disqualify Gentoo for any professional |
20 |
> > environment like this will break automatic upgrades and you cannot roll |
21 |
> > individual fixes for each possible situation via CFM tools like Salt, |
22 |
> > Ansible, Puppet or Chef. |
23 |
> > |
24 |
> > It would be very appreciated if everyone will pay more attention to this |
25 |
> > in future. We can do better. In most cases we can avoid problems like |
26 |
> > this by keeping older ebuilds around much longer for certain key |
27 |
> > packages to help with upgrades. |
28 |
> > |
29 |
> > Thank you. |
30 |
> |
31 |
> Actually, it is possible to manage dependency errors like those. It just |
32 |
> takes a *lot* of elbow grease, and and long, long time time. Especially if |
33 |
> you have museum-grade hardware that these errors are happening on. |
34 |
> |
35 |
> For Perl, I've usually just uninstall everything under virtual/* first, then |
36 |
> try to let it upgrade. Sometimes that "unsticks" something in perl-core |
37 |
> enough to let the upgrades apply, pulling back in any needed items from |
38 |
> virtual/. If that doesn't solve the problem enough to let emerge do an |
39 |
> upgrade cycle, I'll try using just the @system target, or start yanking |
40 |
> things out from perl-core/* one-by-one until emerge shuts up and does what |
41 |
> it is told. |
42 |
> |
43 |
> Also, *always* check for libperl-www being in the package list. It's |
44 |
> usually sucked in by way of dev-util/intltool and is responsible for ~35-40 |
45 |
> perl packages alone being pulled in. If that's in the list, try |
46 |
> uninstalling just that one, then run a depclean to remove all of its |
47 |
> dependencies and then see if the upgrade will work. If the upgrade tries to |
48 |
> drag intltool or libperl-www back in, use --exclude to hold it out for later. |
49 |
|
50 |
For me, Qt packages are often a blocker... It seems that on |
51 |
slot-change, portage isn't able to consider all reverse dependencies |
52 |
for rebuilt - or rather: It doesn't consider that the old slots |
53 |
will/can be uninstalled later. I think something similar happens for |
54 |
perl. Usually, I can solve this by adding `--reinstall-atoms="$(qlist |
55 |
-IC dev-qt/ dev-perl/)" to the cmdline, then add the remaining reverse |
56 |
dependencies that need to be rebuilt, too, but portage doesn't |
57 |
consider for some reason. Usually, that catches more packages than |
58 |
actually really need to be rebuilt but it cuts down the messy |
59 |
dependency graph in the error message a lot and enables me to finally |
60 |
handle it in a sane way. Python upgrades, tho, are a lot weirder and |
61 |
harder to resolve because it involves portage itself. The latest EAPI |
62 |
bump was a hard one when I didn't update portage for some time (yes, |
63 |
it's recommended to do that but that's not always possible for |
64 |
production containers, and there's also not always time to do that, |
65 |
and least we are working with containers now with cut down |
66 |
dependencies, staging and cloning updates with |
67 |
single-purpose/single-service containers is a lot less headache). |
68 |
|
69 |
I'm not sure what the problem is here: Somehow portage isn't able to |
70 |
reach the final result. But then, maybe it should consider not |
71 |
upgrading all packages at once and even consider less recent package |
72 |
versions for dependency resolving. This probably would explode the |
73 |
whole resolver algorithm - and that needs to be optimized properly. |
74 |
But I'd rather prefer to run portage twice or even more often, if it |
75 |
at least resolves to an intermediate solution with not always the |
76 |
latest package versions. |
77 |
|
78 |
But I'm pretty sure one central problem is portage not always |
79 |
considering packages for rebuilds properly - and that seems to mostly |
80 |
happen on slot changes when there are mixed reverse dependencies: some |
81 |
that depend on a slot, and some that don't. Maybe some resolve |
82 |
candidates are eliminated just too early from the dependency graph... |
83 |
|
84 |
That said, I'm usually able to avoid uninstalling packages by using |
85 |
`--reinstall-atoms`, and sometimes it just needs an `emerge |
86 |
--deselect` because something stuck it into the world file for reasons |
87 |
I cannot understand (I'm really picky about what goes into my world |
88 |
file and try to keep it at the minimum needed). |
89 |
|
90 |
|
91 |
> That all said, am I alone in thinking that the way Portage emits error |
92 |
> messages about dependency resolution problems is extremely messy and |
93 |
> border-line unreadable at times? The current way it outputs depgraph errors |
94 |
> feels like something I'd expect from a --debug switch. We've got a |
95 |
> reputation for being playful and colorful on the command line with our |
96 |
> tooling, so I would wonder if that depgraph output couldn't be made to |
97 |
> look....nicer? |
98 |
|
99 |
Yep, it's hard to read. It takes a steep learning curve to properly |
100 |
read those messages and understand what they are telling you, and then |
101 |
an even steeper learning curve to figure out what action actually has |
102 |
to be taken. And it doesn't help when portage omits packages with "and |
103 |
27 other packages with a similar problem" when exactly those are the |
104 |
ones I'd need to manually stick to the reinstall list. And something |
105 |
in my head says: "Why doesn't portage just consider those for |
106 |
automatic reinstall?" - well, probably it did, I'm pretty sure it did. |
107 |
But something eliminated those too early from the resolve. Increasing |
108 |
the backtracking usually does exactly nothing except the resolve runs |
109 |
**a lot** longer. |
110 |
|
111 |
Regards, |
112 |
Kai |