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

[Duncan <1i5t5.duncan@cox.net>]

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