========================== Fedora dependency troubles ========================== By Hans Christian Studt 31. March 2007 "I think it wound be useful if the YUM and RPM tools supported the ability to upgrade the subset of packages that do not suffers dependency problems even if another subset of packages can not be upgraded because of dependency problems all in the same process." I have been using Fedora since version 1 or 2 and I never managed to upgrade to the next version. In the past I mostly choose to do a fresh install in order to fix problems or because I had moved on to new hardware. Until begin of march 2007 I have been running Fedora Core 5 on a AMD 64bit system, which work quite fine and have been configured to my needs, and I did not want to do a complete fresh install and reconfiguration to get Fedora Core 6 installed. I use some software repositories like atrpms, freshrpms and livna that provide software like games and multimedia codecs etc. that Fedora does not provide. Until now the use of non-standard repositories have almost in it self been a show stopper when it comes to upgrading to the next Fedora version. Now full forward to march 2007. One day in the beginning of march I decided that I would like to get a shot at the beryl stuff, but only to discover that a packaged version is only available for Fedora Core 6. It is now 2 weeks since I completed the upgrade so there may be some gaps in may recollection of what I actually did and in which sequence it happened. Step 1 ====== Fortunately there is a "easy" way to upgrade from Fedora Core 5 to 6 using yum. First I disabled to non-standard repositories so they did not interfere with the upgrade. I managed to upgrade the Fedora version identity to FC6, so from now on yum will use the FC6 repositories and package versions. When I tried to upgrade the installed software to the latest FC6 versions I ended up with 275 packages that could not be upgraded due to dependency problems. After second thoughts I decided to enabled the non-standard repositories because I realised that the fact that non-standard packages may cause some of the problems if non-standard repositories were not available during the dependency processing. That did not change much, but I was not ready to give up. Step 2 ====== I made a bash script that would try to upgrade each of the 275 packages on a one by one basis, with the hope that some of them could be upgraded because they would not be dependent on packages that suffers dependency problems. Some packages were installed this way, but not many so it did not really help that much. Note I think it wound be useful if the YUM and RPM tools supported the ability to upgrade the subset of packages that do not suffers dependency problems even if another subset of packages can not be upgraded because of dependency problems all in the same process. I am well aware that you can exclude individual packages from the YUM process. Step 3 (optional) ================= I decided to remove some of the more complex application that had dependency problems as it would be easy to re-install them after any other dependency problems were resolved. openoffice.org eclipse ant I did this in an effort to reduce the number of packages to upgrade and number of dependency problems that needs to be resolved. Step 4 (optional) ================= I decided to remove most development packages as I do not real need them and it would be easy to re-install them after dependency problems were resolved. To get a list of installed development packages I entered the following command from a terminal console rpm -qa | egrep "[-]devel[-]" | sort I tried to remove these packages one at a time by entering the following command followed by a space and the actual package name rpm -e e.g. rpm -e freetype-devel Some of these packages needs to be removed in a group of two or more packages so that mutual dependency are not broken in the process. I did this in an effort to reduce the number of packages to upgrade and number of dependency problems that needs to be resolved. Step 5 ====== I then began to investigate some of the packages that caused dependency problems, and found out that most of them was installed more than once. It turned out that because this was a 64bit system many packages had both the i386 version and the x86_64 version installed. It also looked like the i386 version of some packages could be the trouble maker, so I tried the remove that version. Now that provided some progress as some packages now were upgraded without dependency problems. I then produced a list of all packages which were installed in more than one version by entering the following command rpm -qa | sort | uniq -c | sort -nr Next step was attempting to remove the i386 version of all packages installed more than once. I tried to remove these packages one at a time by entering the following command followed by a space and the actual package name with the extension .i386 added to it rpm -e e.g. rpm -e gnome-vfs2-2.14.2-1.i386 Some of these packages needs to be removed in a group of two or more packages so that mutual dependency are not broken in the process. Totally i managed to remove approx. 50 i386 versions of packages. Step 6 ====== The number of packages was now down at 261. As these 261 packages that needed to be upgraded may very well require an upgrade of any number of the total 1477 packages that I have installed, so I decided to try to do another one by one upgrade of each of these 1477 packages using the bash script used in Step 2. This managed to upgrade some single packages, but must be repeated several times because dependency are being resolved from the bottom layer of packages and upward. Step 7 ====== Not all packages can be upgraded one by one because dependency problems can only be resolved when a group of packages are upgraded together. This was the case with the packages dbus, hal, avahi and gnome-vfs2, so I upgraded them by entering the following command yum -y upgrade dbus-1.0.1-9.fc6 hal-0.5.7.1-2.fc5 avahi-0.6.16-2.fc6 gnome-vfs2-2.16.2-2.fc6 Step 8 ====== Finally I managed to upgrade all outstanding packages to Fedora Core 6. Step 9 ====== yum -y install beryl After thoughts ============== This process was performed over approx. 3-4 days where at most of the time were spend running bash scripts. I may have spend 3-4 hours investigating problems and trying to manually upgrade groups of packages etc. I do not know if it is possible to automate any of the problem solving steps above. I guess the yum tool during execution collects data on the dependency hierarchy and could be modified to try to upgrade packages that are not affected by any of the other discovered dependency problems. Anyway I any quite happy that I am now successfully upgraded to FC6 including all the additional repositories I use. I realise that my approach to this upgrade are kind of a brute force approach combined with a bottom up approach. By Hans Christian Studt 31. March 2007 Copyright 2007 Hans Christian Studt All Rights Reserved.