Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 13:58:44
Message-Id: pan.2011.09.20.13.57.21@cox.net
In Reply to: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Pacho Ramos
Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted:

> I haven't ever tried it but, what would occur if that people with really > updated systems simply unpack an updated stage3 tarball in their / and, > later, try to update?
I believe it was Mike that pointed me at the error in that, which once he mentioned it I recognized it due to having to recover from the same problem but for a different reason.[1] The problem is that since the stage-3 untarring bypasses portage, the files on the live filesystem no longer match what portage believes to be installed. The filesystem right after the untarring should be functional to at minimum the level of the stage tarball, but as soon as one starts emerging new packages, there will be issues since the old versions won't be properly removed, because the files no longer match what's in the database. FEATURES=unmerge-orphans is a dramatic help cleaning up the mess (it wasn't around when I had the problem for other reasons, unfortunately), but I don't believe it can or will catch everything. There's definitely a stage-3 tarball method that works and is actually the recommended method for updating real old installations, but it involves using a chroot and effectively installing from scratch in the chroot, then booting to it instead of the existing installation. That's basically a special-case of case #5 in the Gentoo Linux Alternative Installation HOWTO, installing Gentoo from an existing Linux distro[2]. The only bit of note is that the existing distro happens to be (an outdated) Gentoo as well, instead of whatever other distro. --- [1] My situation was separate /, /usr and /var partitions, each with backups, but ending up in a recovery situation where the backups weren't in sync time-wise. Thus portage's package installation database on /var was out of sync with the actual files on / and /usr. I was still finding the occasional stale file triggering issues, over a year later! It's for this reason that by personal policy, everything portage installs to is on the same partition, along with the installed package database, so if I end up using a backup of that partition, the database is by definition in sync with what's installed since it's all the same backup partition. [2] http://www.gentoo.org/doc/en/altinstall.xml#doc_chap5 I used this HOWTO from Mandrake back in 2004, for my original Gentoo/~amd64 install. For that matter, the gentoo/amd64 32-bit chroot guide is a variant on this idea as well, except that for just a 32-bit chroot, the host-system kernel and services can be used, so they don't need built. But I did a variant on /that/ for my netbook build image, located on my main machine since it's far more powerful than the netbook, and of course I built the kernel and system services for it, tho I only actually ran them after installing them to the netbook. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman

Replies