1 |
On 11/3/2021 11:03, Thomas Deutschmann wrote: |
2 |
> Hi, |
3 |
> |
4 |
> it is currently not possible to smoothly run a world upgrade on a 4 |
5 |
> months old system which doesn't even have a complicated package list: |
6 |
|
7 |
[snip] |
8 |
|
9 |
> This is not about finding solution to upgrade the system (in this case |
10 |
> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is |
11 |
> about raising awareness that Gentoo is a rolling distribution and that |
12 |
> we guarantee users to be able to upgrade their system when they do world |
13 |
> upgrades just once a year (remember: in my case the last world upgrade |
14 |
> is just 4 months old!). If they cannot upgrade their system without |
15 |
> manual intervention, we failed to do our job. |
16 |
> |
17 |
> Situations like this will disqualify Gentoo for any professional |
18 |
> environment like this will break automatic upgrades and you cannot roll |
19 |
> individual fixes for each possible situation via CFM tools like Salt, |
20 |
> Ansible, Puppet or Chef. |
21 |
> |
22 |
> It would be very appreciated if everyone will pay more attention to this |
23 |
> in future. We can do better. In most cases we can avoid problems like |
24 |
> this by keeping older ebuilds around much longer for certain key |
25 |
> packages to help with upgrades. |
26 |
> |
27 |
> Thank you. |
28 |
|
29 |
Actually, it is possible to manage dependency errors like those. It just |
30 |
takes a *lot* of elbow grease, and and long, long time time. Especially if |
31 |
you have museum-grade hardware that these errors are happening on. |
32 |
|
33 |
For Perl, I've usually just uninstall everything under virtual/* first, then |
34 |
try to let it upgrade. Sometimes that "unsticks" something in perl-core |
35 |
enough to let the upgrades apply, pulling back in any needed items from |
36 |
virtual/. If that doesn't solve the problem enough to let emerge do an |
37 |
upgrade cycle, I'll try using just the @system target, or start yanking |
38 |
things out from perl-core/* one-by-one until emerge shuts up and does what |
39 |
it is told. |
40 |
|
41 |
Also, *always* check for libperl-www being in the package list. It's |
42 |
usually sucked in by way of dev-util/intltool and is responsible for ~35-40 |
43 |
perl packages alone being pulled in. If that's in the list, try |
44 |
uninstalling just that one, then run a depclean to remove all of its |
45 |
dependencies and then see if the upgrade will work. If the upgrade tries to |
46 |
drag intltool or libperl-www back in, use --exclude to hold it out for later. |
47 |
|
48 |
That all said, am I alone in thinking that the way Portage emits error |
49 |
messages about dependency resolution problems is extremely messy and |
50 |
border-line unreadable at times? The current way it outputs depgraph errors |
51 |
feels like something I'd expect from a --debug switch. We've got a |
52 |
reputation for being playful and colorful on the command line with our |
53 |
tooling, so I would wonder if that depgraph output couldn't be made to |
54 |
look....nicer? |
55 |
|
56 |
-- |
57 |
Joshua Kinard |
58 |
Gentoo/MIPS |
59 |
kumba@g.o |
60 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
61 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
62 |
|
63 |
"The past tempts us, the present confuses us, the future frightens us. And |
64 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
65 |
|
66 |
--Emperor Turhan, Centauri Republic |