Warning: long post. On Sun, Mar 28, 2004 at 11:40:45AM +0200, Oded Arbel wrote: > ביום ראשון 28 מרץ 2004, 10:04, נכתב על ידי Gal Goldschmidt: > > From my past experience it's a pain. > > I had to format and reinstall, since the upgrade left the system in an > > unstable state. > > Maybe the upgrade is smother on the new version, My last Mandrake > > installation was around the 9.1. > > My experience shows that you can easily upgrade a year old installation with > the latest Mandrake w/o consequences. the older the install and the weirder > your setup, the harder it will get, but for the "standard" simple install it > will be nothing more then "next"->"next"->"finish". > > That being said, generally speaking I suggest either of two modes of keeping > Mandrake up to date: either (a) re-install every time you have a new version > (make sure your /home is on another partition and you don't have important > data elsewhere and then format / and reinstall and reconfigure - takes 2~3 > hours at most to get your system back up) or (b) upgrade your system live > using URPMI. this is relativly safe and very easy to do, but I suggest you do > it for every new version that comes out (every 6 months or so) otherwise the > difference between a year old install and a current one will probably be too > great to make it painless.
I have a generic mistrust of taking the system down and performing an upgrade. I prefer to simply upgrade using urpmi (as Oded mentioned above) or apt or whatever. In the past it was through using rpm. I recently upgraded my RH7.3 workstation to Centus 3 (a RHEL 3 clone) and yum as the package manager. Initial stages involved some delicate moves (rpm+glibc upgrade together can be painful), but after that things went pretty well. A "live" upgrade from one distro to the other may work, but has many pitfalls. There are simply too many little places in the upgrade process where an installation/upgrade/removal of a package can cause an error and stop the process in the middle. Thus it will generally "work" only if others have tried and debugged it before. Debian has many people upgrading from stable to unstable/testing/frozen in various stages, and thus there is a generally a good chance for the process to be successful. Another atvantage is that it has a large pool of its own packages, and for a standard setup you need very little non-official packages. This decreases the chance of problems incured by interaction with non-standard packages. A number of advices if you decide to take this upgrade route: 1. Don't be tempted to use --force. Don't be tempted to use --nodeps and co. unless it is really necessary. And even then think twice. Even if you do: try to fix the problem ASAP, because an unsatisfied dependency can get at you later in the upgrade process. 2. Such an upgrade involves all sort of package dependency conflicts. Sometimes the simplest way to avoid such a conflict is to remove one of the conflicting packages (and all of its dependencies). It is relatively simple to later re-install those packages. 3. Thus it is a good idea to decide in advance which packagess you really need, and which you're prepared to remove. E.g: both gnome and KDE have a complex set of libraries and thus there is a reasonable chance of issues with them. And If the upgrade involves an upgrade of apache and this is not a production web server, you may consider removing apache and mod_* altogether. 4. A stable environment: I would stay away from gnome/kde for the time of upgrade: those desktops are relatively complex, and there is a resonable chance that you will remain with a non-functional desktop. Use a simpler desktop (Did I ever mention I like IceWM?) or run from the console. Also consider running everything in a screen session, so you could continue it if something happened to the terminal. 5. I have a useful tool in the shape of a statically linked busybox binary with everything compiled in (including tar, nc, unrpm, httpd and others. Kitchen sink not included yet). I built it with uclibc to avoid the problem of RH9 and co. with older statically-linked binaries. Not simple to build but has already proved very useful at times. 6. Remember that even after you have unlinked files from your filesystem, they may still live on the disk if something still uses them. e.g: if you have an xterm open and you upgrade xlibs, your session will still use the older ones. This is quite handy (during the above-mentioned installation I kept using the same desktop and the same old galeon from RH73 even though it was long ago uninstalled). > > > > 3. Do we have any distribution (beside Gentoo) that do not > > > require upgrading ? I.e. once installed, some "emerge -world" > > > always (!) bring latest updates for all packages ? > > > > Definitely Gentto is the best, but if your machine is not a >2GHz CPU and > > you don't have a day or two for the installation, you should check Debian > > or a Debian based distro, The upgrade apt-get update; apt-get upgrade no > > need to reformat or reinstall from scratch you can move from stable to > > unstable very easily and the machine usually won't break too much ;-). Does it really work? E.g: You would still have a hard time getting over a major glibc upgrade. Once you upgrade a library you need to rebuild all of the programs that use it. So I figure that with such an upgrade you'll need to rebuild the same programs a number of times. If you want to take shortcuts you should probably do so with some care. I believe that a good binary distribution makes such an upgrade easier, not harder. > P.S. > A Mandrake URPMI tip: update on sundays. Why? an errata release cyle? or availability of mirrors? BTW: what's the urpmi equivalent of 'apt-cache search' ? > > -- > Oded > > ::.. > If you don't know where you're going, any road will take you there. > -- Lewis C. Carol > > > ================================================================To unsubscribe, send > mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] -- Tzafrir Cohen +---------------------------+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---------------------------+ ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
