1 |
Hello, |
2 |
|
3 |
On Sat, 13 Aug 2016, Andreas K. Hüttel wrote: |
4 |
>Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw: |
5 |
>> I?m trying to upgrade portage because I?m getting a message that it |
6 |
>> needs to be able to work with EAPI 6 packages and can only do EAPI 5. |
7 |
[..] |
8 |
>If you see this now, your production server hasn't been updated for a long |
9 |
>time... |
10 |
> |
11 |
>As a last resort, you should be able to run a "non-installed" portage version |
12 |
>to update your system once. Manually download and unpack a recent portage |
13 |
>tarball somewhere temporary and then run as root something like |
14 |
> |
15 |
>porto tmp # ./portage-2.3.0/bin/emerge -uDNav world |
16 |
> |
17 |
>This can update your system to the newest state, including updating the |
18 |
>installed portage. Afterwards you won't need the temporarily unpacked portage |
19 |
>anymore. |
20 |
|
21 |
Yep. BTDT. I had a then 4-4.5 year old gentoo quite broken by being |
22 |
partly updated until portage/emerge broke and much else didn't work |
23 |
anymore (gcc/make/python/emerge). So, I booted something else, mounted |
24 |
gentoo somewhere (say /mnt), unpacked a fresh stage3 _into_ that |
25 |
mountpoint into /stage3 (i.e. "/mnt/stage3"), chrooted there (with the |
26 |
usual /sys, /proc, /dev bind-mounts) and then ran stuff from the |
27 |
/stage3/ tree[1] until the basic stuff (mainly above mentioned 4) was |
28 |
fixed. From then on it mostly went "smooth", by the "textbook", |
29 |
considering. Yeah, lots of conflicts and whatnot because of moves, |
30 |
renames and new deps etc.pp. It was a bit tedious, but not difficult. |
31 |
|
32 |
And this general tip came out of it: unmerging stuff helps to break |
33 |
tangles. Like slashing the Gordian Knot ;) |
34 |
|
35 |
Before you yourself get stuck in the same tangles that emerge did, |
36 |
be bold, take note and switch to a "unmerge + reemerge" strategy! |
37 |
I.e. take one offender, note it down (textfile and/or paper), unmerge |
38 |
it, try a re-emerge of that offender or a @world without it. Keep |
39 |
adding to the "offenders" list until emerge comes up "clean". Then try |
40 |
re-emerging the offenders one by one. |
41 |
|
42 |
It's one of the first things I do when weird stuff/conflicts crop up. |
43 |
Before I mess with useflags and masks and whatnot, I unmerge both |
44 |
tangled packages (and keep track of anything I unmerge in a textfile |
45 |
or so!) and then try to merge only those (with '--pretend --tree' at |
46 |
first). Emerge IMO handles the "install" case much better and the |
47 |
conflicts are often much clearer, "obsolete" deps can be ignored |
48 |
and/or handled later by "emerge @preserved-rebuild". |
49 |
|
50 |
And once I've figured out what's going on, it often is just one |
51 |
useflag, or one (un)mask or something else in /etc/portage/package* to |
52 |
clear it all up. |
53 |
|
54 |
And finding that is much easier doing it one-by-one. |
55 |
|
56 |
Of course, you can't unmerge stuff like gcc/make/python/portage just |
57 |
like that, that's when an unpacked /stage3 comes into play. But you |
58 |
should not need that until your system is _way_ outdated (as was |
59 |
mine). |
60 |
|
61 |
Anyway: so, yes, you can use a unpacked up-to-date /stage3 for |
62 |
bootstrapping an update once your system is so (ridiculously) outdated |
63 |
that a normal update breaks, and not only for installing a new system |
64 |
:) Of course, you'll have to deal with new/renamed/moved/gone packages |
65 |
and such stuff, but that's to be expected[3]. And IIRC that strategy |
66 |
had me upgrading quite smoothly to the new perl-5.24 (from 5.20 or |
67 |
.22?) just recently. At times, emerge _does_ get somewhat stuck. And |
68 |
it's output gets confusing to match. |
69 |
|
70 |
But! Usually, when your system is not too much out of date, emerge |
71 |
does a _very_ good job, it's output is a bit hard to read though, |
72 |
something IIRC the devs are the first to admit, but as Neil and others |
73 |
prove here often (I'll try to get more into helping too), you can get |
74 |
used to it and pinpoint the actual reason for emerge barfing tons of |
75 |
text on you. |
76 |
|
77 |
-dnh |
78 |
|
79 |
[1] IIRC by adjusting PATH and LD_LIBRARY_PATH until I got the tools. |
80 |
|
81 |
Once that was done, I (rebooted and?) re-emerged those "natively" |
82 |
from the actual gentoo with "/stage3" "removed" from PATH. |
83 |
|
84 |
PS: I've done similar stunts with other distros... install only a |
85 |
64bit kernel/glibc/rpm[2] while the repos still pointed to i586 |
86 |
because you updated the repos to the new version but not the |
87 |
repo-config to x86_64? Bad idea! But "fun"! (boot something, mount |
88 |
target as /mnt and an ISO under /ISO) and then |
89 |
cd /ISO/../x86_64/; |
90 |
rpm --root=/mnt --test -ivh package_manager.rpm \ |
91 |
more_and_more_rpms ../noarch/even_some_more_rpms |
92 |
until the package_manager ran. Much like emerge in my gentoo case. |
93 |
|
94 |
And yes, I still run both systems, updated since then quite a bit, |
95 |
everything checks out, I even got rid of leftover i586 packages on |
96 |
that at-first-fouled-up-switch-to-x86_64 system. |
97 |
|
98 |
[2] or the other way round? Anyway: basically nothing but the kernel |
99 |
itself ran. So, boot something else, and ... |
100 |
|
101 |
[3] and which is why I like stable stuff like TeX, WindowMaker, mutt, |
102 |
tin, mc, joe, (X)Emacs, lynx/links/w3m or even netscape/seamonkey |
103 |
that does not get incompatibly rewritten from scratch every couple |
104 |
of years. I'm gazing at you KDE! Since KDE2 in it's early betas! |
105 |
|
106 |
-- |
107 |
Oh, naturally - I'm not a cruel man. A viciously vindictive grudge- |
108 |
bearing wee Bastard, yes, but not cruel. -- J. C. 'Jim' Andrew |