[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
On Sunday 30 September 2001 1:11 am, Keith Abraham wrote about [LUG] First Post-Help: > Hi all at dclug > As seems usual my first post is a request for help. That's what we're here for! (I think.) > I'm very new to Linux having used SuSE 7.1 only since July. I found > it relatively easy to install 7.1 as the sole system on my machine and > am very happy with it. > My problem is upgrading KDE 2.0 to KDE 2.2.1. I have downloaded > the relevant .rpm files from SuSE. But it seems to me that as KDE is > the interface to the Linux OS surely KDE will crash when I try to upgrade > it? Do I have to close down KDE 2.0, remove it, and install KDE 2.2.1 > using a terminal and if so how do I do that? > I've tried looking on the SuSE and KDE sites for instructions on how > to do the upgrade but I can find nothing which seems to apply to upgrades. > I would be grateful if someone give me step-by-step instructions to > upgrade KDE 2.0 to KDE 2.2.1. > > Regards Keith I can't speak for a Suse installation, I haven't tried, but I have upgraded KDE within Linux Mandrake 7.2, using the CD from Linux Emporium which I described in an earlier post. I had KDE running, loaded Mandrake Update (which normally looks for the rpm's online) and changed the source location to /mnt/cdrom. That's the only Mandrake-specific part of it. The installation of the rpm's can be achieved whichever way you like, it's the sequence that appeared more important. So I then moved to selecting the packages to upgrade a few at a time. Each conflict or dependency would then be noticed almost immediately and the packages installed in the correct sequence. (e.g. kdesupport-devel and kdesupport together but before kdeadmin.) Note that I installed some KDE components at the same time as their supporting rpm's. I'm not sure how to do this from the command line, so check out a GUI RPM program in Suse that is similar to Update. That'll avoid all the hassle explained below! KDE isn't an interface to Linux, as such, it's a program like any other and it runs using the X server. The interface is the shell - bash on Mandrake and Red Hat. The X server itself isn't being upgraded when you upgrade KDE. There's no need to shut down KDE, the new KDE logos will show up when you logout and log back in, individual KDE programs will run the new code when you start them, e.g. if you upgrade KMail, the new KMail program will run when you next run KMail, independent of the rest of KDE. What you WILL notice, is that upgrading KMail will give an error if crucial parts of KDE (the dependencies) haven't been upgraded already. If you want to do it from a the command line, open a terminal/shell window as normal, you can leave KDE running. That'll make it easier to find help if you get stuck half way. Use the dependencies to sort out the sequence. e.g. with KMail, if you get a dependency error when you try to install it, make a note of the dependency, find the rpm and try to install that - in effect you track back through KDE until you find the packages that don't need others to be installed first. So to track back through KDE, you can use rpm -i <rpmfile> from a terminal and that'll complain about dependencies and it'll list the packages that are needed before that one can be installed. Then it's simply a case of trying rpm -i with each of the listed dependencies until you get back to a point where it'll install without complaint, then you work forwards, using rpm -i for all the packages that complained previously. You still install the same number of packages, it's the sequence that matters. There are some packages that are a better starting point than others, anything relating to 'core' may be a good start, and often '-devel' packages need to be installed AFTER the main package (the one with the same name but without the '-devel' suffix). That's the useful thing with Linux, it won't easily allow you to install the wrong package. Windows will gladly let you install anything, only to find that it won't run afterwards because it needs xxx.vxd or yyy.dll - even worse, Windows will then usually salute you with the BSOD and will crash when you have to reboot, complaining about the lack of xxx.vxd or yyy.dll!!!! One final word of warning, not on KDE but on rpm (only because it happened to me): If you ever run rpm -i kernel.<whatever>.rpm, MAKE SURE YOU RUN LILO afterwards!!!! Just type LILO in a terminal window as root. It won't take a minute, it WILL save you a LOT of work because otherwise your new system will run fine (using the old kernel) until you reboot and then LILO will simply hang. You'll have no telnet access, no http access, no shell access, no ssh access, nothing. You won't be able to log in as anyone, no way, no how. You'd better hope you have that boot floppy handy! -- Neil Williams #-#-#-#-#-#-#-#-# linux@xxxxxxxxxxxxxx neil@xxxxxxxxxxxxxx neil@xxxxxxxxxxxx www.codehelp.co.uk -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.