Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

[Pacho Ramos <pacho@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]

El mar, 20-09-2011 a las 13:57 +0000, Duncan escribió:
> 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.

I thought that problem wouldn't occur as, if I don't misremember, stage3
tarballs include /var/db/pkg files for its packages and, then, an
"emerge -e world" just after unpacking stage3 would use
updated /var/db/pkg contents from stage3 and, for the remaining files,
they would be updated as soon as emerge -e world ends (maybe this and
"unmerge-orphans" would solved most of the issues)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]