On Sun, 2006-10-29 at 23:02, David G. Miller wrote: > >> > >All the more reason to use the old timey /usr/local system > >upgrades won't touch it. Maybe we need to adjust our tinfoil and go > >retro, the old timers had methodologies that may need revisiting. Ric > > > That approach worked a lot better before X. Something like the change > from XFree86 to X.org screws everything up since a lot of users like > WIMP interfaces. Same for any significant change to the GUI. > > It would be nice to see something like: > > 1) Critical system functionality -> gets upgraded. > 2) Common applications -> upgraded or at least at reasonable stab at it. > 3) Other stuff -> install new config and save the old as rpmsave. > > The goal would be that a functioning system gets upgraded to the new OS > release that, for the most part, works. That is, everything works but > it's possible that some settings are left to the admin/user to bring > forward. It's really time to do something more drastic, like a scripted Xen and/or VMWare migration where step 1 is to convert your running system into a virtual machine hosted by your known working kernel, step two is to update the virtual machine to the new version while it is isolated from hardware quirks, step 3 is to install a new kernel on the host (and if this has problems with your hardware, back out until the updates permit it), and the optional step 4 is to migrate the virtual server back up to the real host OS. Or, convince the kernel developers that changing driver binary api's and removing header files is a bad idea... -- Les Mikesell lesmikesell@xxxxxxxxx -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
