Gentoo Archives: gentoo-dev

From: Joshua Kinard <kumba@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: You currently cannot smoothly upgrade a 4 months old Gentoo system
Date: Wed, 03 Nov 2021 22:15:34
Message-Id: c8ab772c-a1ba-9020-dc66-4b4a52118024@gentoo.org
In Reply to: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system by Thomas Deutschmann
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

Replies