From: Laurence Perkins <lperkins@openeye.net>
To: "gentoo-user@lists.gentoo.org" <gentoo-user@lists.gentoo.org>
Subject: RE: [gentoo-user] python, my nemesis
Date: Mon, 20 Sep 2021 16:02:56 +0000 [thread overview]
Message-ID: <MW2PR07MB4058EB1F459A6F1843872903D2A09@MW2PR07MB4058.namprd07.prod.outlook.com> (raw)
In-Reply-To: <2945625.CbtlEUcBR6@lenovo.localdomain>
-----Original Message-----
From: Michael <confabulate@kintzios.com>
Sent: Monday, September 20, 2021 8:21 AM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] python, my nemesis
On Monday, 20 September 2021 15:52:03 BST Gerrit Kuehn wrote:
>>
>> Just extracting stage3 over everything that is already there?
>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.
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.
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.
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...
LMP
next prev parent reply other threads:[~2021-09-20 16:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 12:50 [gentoo-user] python, my nemesis Gerrit Kuehn
2021-09-20 13:18 ` Michael Orlitzky
2021-09-20 13:56 ` Gerrit Kuehn
2021-09-20 14:29 ` Michael
2021-09-20 14:52 ` Gerrit Kuehn
2021-09-20 15:20 ` Michael
2021-09-20 15:40 ` Gerrit Kuehn
2021-09-20 16:02 ` Laurence Perkins [this message]
2021-09-20 17:19 ` [gentoo-user] " Grant Edwards
2021-09-21 16:29 ` Gerrit Kuehn
2021-09-20 14:34 ` [gentoo-user] " Michael Orlitzky
2021-09-20 15:00 ` Gerrit Kuehn
2021-09-20 15:17 ` Neil Bothwick
2021-09-20 15:30 ` Gerrit Kuehn
2021-09-20 15:47 ` Laurence Perkins
2021-09-20 14:31 ` Gerrit Kuehn
2021-09-20 14:40 ` Gerrit Kuehn
2021-09-20 14:41 ` Arve Barsnes
2021-09-20 14:58 ` Gerrit Kuehn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MW2PR07MB4058EB1F459A6F1843872903D2A09@MW2PR07MB4058.namprd07.prod.outlook.com \
--to=lperkins@openeye.net \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox