On 09/20/11 09:12, Alex Alexander wrote: >> The only real gotcha is if portage is so old that it can't handle the >> binary packages. However, to get around that we really just need a >> set of step-wise binary updates for portage itself so that you can >> sequence it up to something that can install the rest. That will work >> as long as portage doesn't strictly need a newer dependency. If it >> needs a newer python or something then we might need to keep a binary >> package of that lying around - maybe statically linked so that it >> doesn't go further than a few packages.
That won't work nicely. I've done enough system upgrades to have found funny issues along the way, for example package.mask getting in the way or needing a specific package merge order, which won't work if you still have an older glibc installed. >> Something like that really just needs a few tarballs and then an >> up-to-date set of binary stage3 packages. The binary packages could >> be built at the same time the stage3s are made. And, this is really >> just a contingency plan so we don't need to mirror all that stuff - we >> could even just make it torrent-only or something. > > Binary packages are useful, but you can't consider them a true fix to our > problem. In 2011, having to do all this manual work just to keep a system > running seems wrong. Especially when there are other solutions that would > allow > you to avoid all that. I think we can script it away. We do know the last sync time and the last merge time. >From this we can deduce the next snapshot we want to go to - use emerge-webrsync to fetch a snapshot (06-2008), emerge -eK system (this will break a few of the other installed packages), progress to next snapshot (01-2009), repeat. (I think a 6-month snapshot distance is a good balance between reliability and speed) (btw: you can generate most of the binpkgs you need from a stage3 automatically) Along the way you will have a few blockers which can mostly be figured out a priori (coldplug, hal, portage-python, ...) and for the most part scripted away too. (Another gotcha: kernel-udev-glibc, at some point you may have to reboot with a recent enough kernel just to be able to get a working glibc) Then you've upgraded @system to something from this decade and you can try updating the rest (which will have its own share of blockers etc) > Implementing something like my proposal would save a lot of systems with > minimal cost and make Gentoo more reliable in the public (and corporate) eye. > >> Or we could do what was proposed in the past and say 1 year and you're >> done. That slows us down a little, but has zero overhead. > > IMHO, waiting for a year to push a serious change is unacceptable. We're a > bleeding edge meta-distro, I'm sure we can do better ;) > Doesn't need a year. We have all the bits lying around, if I weren't so lazy I'd have started with a 2006.0 stage3 just to see how much blocker removal and interaction it needs. Make it into a nice script and blam, insta-update.
