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

[Pacho Ramos <pacho@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

El mié, 21-09-2011 a las 04:00 +0000, Duncan escribió:
> 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.
> 

Then, maybe people wanting to update really old systems should be guided
to get a precompiled updated kernel, probably the one used in liveCDs,
no?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]