public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 13:57:22 +0000 (UTC)	[thread overview]
Message-ID: <pan.2011.09.20.13.57.21@cox.net> (raw)
In-Reply-To: 1316524141.1711.0.camel@belkin4

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




  parent reply	other threads:[~2011-09-20 13:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-19 22:14 [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem Alex Alexander
2011-09-19 22:53 ` [gentoo-dev] " Duncan
2011-09-20  0:46   ` Rich Freeman
2011-09-20  1:44     ` Duncan
2011-09-20  7:12     ` Alex Alexander
2011-09-20 10:43       ` Patrick Lauer
2011-09-20 10:28     ` Brian Harring
2011-09-20 10:40       ` Ciaran McCreesh
2011-09-20 11:07         ` Brian Harring
2011-09-20 11:27           ` Ciaran McCreesh
2011-09-20 13:33         ` Ulrich Mueller
2011-09-20 10:50       ` Dirkjan Ochtman
2011-09-20  6:56   ` Alex Alexander
2011-09-20 13:09 ` [gentoo-dev] " Pacho Ramos
2011-09-20 13:16   ` Pacho Ramos
2011-09-20 13:16   ` Michał Górny
2011-09-20 13:25     ` Pacho Ramos
2011-09-20 13:57   ` Duncan [this message]
2011-09-20 14:23     ` [gentoo-dev] " Pacho Ramos
2011-09-20 17:00   ` [gentoo-dev] " Patrick Lauer
2011-09-21  4:00     ` [gentoo-dev] " Duncan
2011-09-21 13:24       ` Pacho Ramos
2011-09-20 15:19 ` [gentoo-dev] " Zac Medico
2011-09-20 15:28   ` Zac Medico
2011-09-20 17:03   ` Patrick Lauer
2011-09-20 17:14     ` Rich Freeman
2011-09-20 17:48       ` Alec Warner
2011-09-20 20:03         ` Michał Górny

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=pan.2011.09.20.13.57.21@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@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