On Wednesday 19 February 2003 09:50 am, James Sparenberg wrote: > On Wed, 2003-02-19 at 09:24, Luca Olivetti wrote: > > Jack Coates wrote: > > >>How is the path from 9.0 to 9.1? Is it just a matter of selecting > > >> upgrade and letting it do it's thing? Has anyone verified this? (I > > >> remeber when redhat said you could do this, 4 server reinstalls > > >> later). > > > > > > supposedly one inserts the new CD and selects LiveUpdate. YMMV. > > > > And then spend the best part of a weekend fixing the breakage (if you > > manage to). > > > > Bye > > Actually I've had luck with it since about 8.1... in fact I upgraded a > 7.2 box to 9.0 straight out. Problems are. > > 1. If you have modified many of your config files you'll find .rpmnew > extensions all over the place. Best way to find them is to update the > locate dbase and do locate rpmnew. > > 2. Live-update is way to slow... boot and do upgrade ... still slow but > a factor of 5 faster than liveupdate. (it errors too much on the side of > caution.) > > 3. If you did it from source (not source rpms) things in these areas > might get mucked. RPM doesn't know from tarballs. > > 4. Fastest way is to still do an install keeping your partitions and > /home. (shear time factor.) > > James
rpms are not dpkgs and don't follow all the rules that makes dpkg preparation such a nightmare and keeps Debian out of date. As a result rpms have limitations.... For one, if you have a %postun stanza in the rpm spec file which removes a link that was made by the rpm either during installation or in the %post stanza and you select "update", the %postun stanza is the last thing to run and blooey--no more link. There is a way around it using a cat and an at in the %post and making a temporary filw that re-sets the link and then self-destructs, which will run only during install (failing to make the link a second time) or after update (because the at sets the temp file as a script to run a couple minutes later), and I did supply QA at mandrake with a screening program to check for the situation with srpms and identify those needing modification. The second is packaging/library naming. RPM can handle some situations acceptably, but splitting one package into three in the next release is not one of them, and this is often done for valid engineering reasons. The point is, want smooth updates, use Debian or at least dpkg and apt-get, but you PAY for it with the rules associated with the dpkg and the developer time necessary to make one and to keep it within rules, which tends to keep Debian seriously behind the leading edge, even with the "unstable" stuff. As always, There Aint No Such Thing As A Free Lunch. You make your choices and you take your chances. Civileme
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
