Re: [gentoo-user] EAPI packages

[hw]

David Haller schrieb:
> 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.

How would it fix the system you chrooted from?  Doesn´t it remain limited
to the chrooted environment?

> 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 ;)

When I unmerge stuff, that stuff doesn´t work anymore, so I´d have to
do that at night.

And now I cannot emerge gentoolkit after unmerging it, which isn´t useful
at all.

> 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.

Still it is extremely tedious.

> 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).

IMO, it´s a silly bug that portage cannot be updated because it cannot
deal with packages it needs to deal with in order to update it.  Someone
created this problem, and they should have thought about what they were
doing and have created a way for the package management to handle this
problem.

> 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
> :)

Three months is not "ridiculously outdated", yet the update doesn´t work.
1.5 years isn´t "ridiculously outdated", either --- maybe a bit old, but
what´s the problem?

> Of course, you'll have to deal with new/renamed/moved/gone packages
> and such stuff, but that's to be expected[3].

Perhaps you can do that when you´re an expert user of the packagage
management and have lots of time on your hands.  I just need to update.

> 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.

There was a version in between, and the update failed.  The output of
emerge is very confusing and doesn´t tell me much, if anything, and
I haven´t had the time to finish the update yet.  That´s going on
for a month or two now, and it´s still not updated.

> 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.

It would already be much easier if emerge wouldn´t print darkblue on black,
which makes it even harder to read the output ...  The messages are cryptic,
and you have to guess what they are trying to tell you.