| 1 |
-----Original Message-----
|
| 2 |
From: Michael <confabulate@××××××××.com>
|
| 3 |
Sent: Monday, September 20, 2021 8:21 AM
|
| 4 |
To: gentoo-user@l.g.o
|
| 5 |
Subject: Re: [gentoo-user] python, my nemesis
|
| 6 |
|
| 7 |
On Monday, 20 September 2021 15:52:03 BST Gerrit Kuehn wrote:
|
| 8 |
>> |
| 9 |
>> Just extracting stage3 over everything that is already there? |
| 10 |
|
| 11 |
>No, I move out of the way the config/data files I want to keep and move them back in after untarring the stage 3. |
| 12 |
|
| 13 |
A less traumatic place to start I find is to unpack the stage3 into /tmp or wherever it's out of the way and then chroot into it and use quickpkg to bundle up newer versions of blocked core utilities. Not needing build deps can quite often simplify the upgrade path enough to get past certain things.
|
| 14 |
|
| 15 |
You can also (with a lot of annoyance) use the new portage that's in the tarball to get past eapi restrictions and whatnot and tell it to install the stuff it builds into your original system's folders. I've even used that to salvage systems that got moved to new hardware with an incompatible set of processor flags. Not straightforward since you have to manage both the build environment in the stage3 and the install environment in the original system, but there's very little you can't fix with this approach.
|
| 16 |
|
| 17 |
Just don't let your system build binary packages for virtual/* under any circumstances. That never ends well. I really need to write up a request to have portage blacklist those by default when buildpkg is enabled...
|
| 18 |
|
| 19 |
LMP |
Archives