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