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: Wed, 21 Sep 2011 04:06:37
Message-Id: pan.2011.09.21.04.00.00@cox.net
In Reply to: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Patrick Lauer
Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted:

> On 09/20/11 15:09, Pacho Ramos wrote: > > > What do you guys think? >> 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? > > Usually things turn ugly - used to be that portage saw that there are > two glibcs installed and unmerges one (oh crummy, you only had one? > better reinstall now ...) and other really disturbing side-effects. > > Just unpacking a stage3 over a live system is a nice game, but rarely > has sane results. You'd need to use a VDB-aware tool like qmerge to do > it cleanly, and then you still don't have a working system (new glibc on > old kernel, new udev on old kernel, lots of situations where things > don't work out)
Thanks, this was far clearer (and more correct) than my attempt. The point about old kernel incompatibilities is going to be especially valid on way outdated installations, and it's something I entirely missed, because especially with the kernel, I tend toward the leading edge rather than trailing, and because I bypass gentoo for the kernel entirely, using my own scripts and upstream git sources, so I don't tend to think in terms of gentoo/userspace kernel deps at all. -- 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