Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 13:57:22 +0000 (UTC)
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:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Pacho Ramos
References:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Pacho Ramos
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Previous by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.