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

[Pacho Ramos]

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)