Duncan wrote: > Andrew D Kirch posted on Sun, 23 Aug 2009 04:05:03 -0400 as excerpted: > > >> Dale wrote: >> >>> While I like your example, if this were to happen and a couple other >>> things has been updated, like for example expat a while back and other >>> similar update nightmares, wouldn't a reinstall be easier and most >>> likely recommended anyway? I have seen this recommended and even made >>> that recommendation on -user a few times. I would also do a reinstall >>> on my own system if I had been gone for 6 months or more. With the >>> updates coming pretty fast for most things, you would most likely >>> recompile most everything on the system anyway. Save the configs and >>> the world file and just start over from a very fresh stage tarball. >>> > > I thought that's what I argued, a bit later -- that at a year or more out > of date, there's enough going to be recompiled anyway, might as well just > do the reinstall from the latest stages, which are at least reasonably > well used and thus reasonably well debugged, rather than trying to > upgrade from a year or more out, something that's much rarer and thus > likely to be a major headache, even if there's nothing deliberately done > to kill it and no known direct incompatibilities. > > And I've used the six-month figure myself. This is what I usually say: > > I try to do it once a week at least (twice a week is better), to keep the > changes to something manageable, even when there's a several-hundred- > package kde upgrade. =:^P But I can see the case being made for once a > month, which would trade a few less updates (intermediate updates you > didn't see) for a bigger headache trying to manage it all, particularly > if something goes wrong. And for those on a routine monthly update > schedule, it's plausible something could delay updating a month or two, > thus making it three months. Heh, that's some people's vacation. > > But at three months, I'd be beginning to consider a reinstall from > stages, tho I'd probably still do the in-place upgrade. But beyond that, > people are really only making it harder on themselves, and by six months, > I really do believe the stages method will be both cleaner and easier, > tho I could still see people trying the in-place method but I doubt I > would. But at a year, honestly, what /are/ people thinking, trying to do > the in-place upgrade? Well, I suppose it wasn't that long ago Gentoo > releng was having problems, and the install media /was/ over a year old, > but even then, at least upgrading from it would be done decently > frequently and thus be decently tested, unlike trying to upgrade in place > from some arbitrary version. But Gentoo's doing rather better in that > regard now, and with automated weekly stages, why on /earth/ would > someone put themselves thru the trouble of an in-place upgrade at a year > out, when they can do it with the far better tested weekly stages, and > just by doing that, they'll be at worst a few weeks out (if there was > some blocker and the stages for their arch hadn't built properly for a > couple weeks). > > >> Guys, if your Gentoo install is 6 months old, you're screwed anyway. >> This should really be a non-issue. I just spent 2 days dealing with >> being 3.5 weeks out of date. Might have been quicker to re-install. Ooh >> well. >> > > Probably not, for 3.5 weeks. Even if that 3.5 weeks is over a big > upgrade, like a new xorg, or kde/gnome/xfce, whatever you run. At that > point, it'll be getting close, but there's still going to be major parts > of the system that are still upto date. But beyond 3 months, it's > questionable, and beyond six, yeah, just go the stages route again, it'll > be less hassle. > > Actually, new thought here! > > How close you are to the USE/C/CXX/LD- flags the stages are built with > could make a big difference, now. If you're running identical flags (or > close enough to it you can consider this), then for the core stages > packages, you can simply install the stages every week, and get at least > somewhat tested "near free" upgrades just doing that. If you know the > update cycle, and grab the stages the day /before/ they update, you've > just gotten yourself six days' worth of "free" testing of the exact same > packages you're using, in /addition/ to the fact that you just saved > yourself a bit of compiling. > > I hadn't thought of /that/ angle before. Interesting idea! =:^) It's > been long enough since I installed (I've been doing rolling updates since > my initial install of 2004.1) that I'm not sure how /practical/ the idea > might be (are most of the packages in the tarball "limited build", thus > needing rebuilt anyway?), but if they're being built weekly now... it > really /is/ an interesting idea! > > But not for me, of course, as like many Gentooers, I have my own ideas > about all those flags, and using distribution defaults brings back bad > memories of the binary based distributions... But maybe for /somebody/. > The /theory/'s there. > >
I think we agree more than disagree. It mostly depends on what updates there has been and if the fancy new portage can get past any blockages and make the needed fixes. I guess whether it is a year, six months or even three months depends on what has been updated, what has to be recompiled and how difficult it is to configure them afterwards. Right now, after the recent python upgrade, I'm recompiling over 60 packages including OOo. If it meant recompiling most of KDE, then a reinstall may be faster. I'm just not sure that portage should be soooo backward compatible as it appears to be now. Dale :-) :-)
