Red Hat Bugzilla – Bug 215621
LOTS of dependencies ERASED
Last modified: 2014-01-21 17:55:54 EST
Description of problem: I was working on a boot block problem (solved) and was watching lots of reboots. I noticed that my previous attempt (months and months ago) to configure ldap was resulting in a FAIl notice during the boot sequence. The smartmon tools also had a problem. To 'clean up' the fail notice, I went to Applications->Add/Remove Software and requested a 'List' of packages. I unclicked the check on smartmontools and clicked the Apply button and everything worked fine. I then did it again, getting the 'List' of packages. I clicked the check to re-install smartmontools and then unclicked the check on openldap. I clicked the 'Apply' button and after awhile, a dialog box came up saying something about dependencies. I said ok.. ---- I was still in the boot block debugging mode and the next time I rebooted, the system hung just beyond the HAL point. It (fortunately) had completed the network configuration (this is my network access/firewall machine). I was able to ssh in from another machine on my local lan. Doing 'ps ax' did not show too much. Xvnc was running, so I tried to log in with vnc. It seemed to get in partway, but did not show the desktop. A little while later, I noticed that my mail was not being picked up. (The problem machine also does fetchmail every 5 minutes to get mail from my ISP). I did 'ps ax'. Neither dovecot nor postfix was running. I went to the directory /etc/rc.d/init.d and saw there was no dovecot or postfix startup script.. I began to panic. Checking /var/log/yum.log around the time of the openldap removal showed 152 system components Erased (gnome-pilot, authconfig, gnome-panel, etc..) See attached list. This list seems a bit excessive. At the minimum, yum should do a check whether erase candidates are critical to the operation of the system.. And give the poor admin another chance (with a big red flag) to reconsider his/her action. Version-Release number of selected component (if applicable): The system is an updated FC5, but probably the problem could also happen with FC6. cat /proc/version Linux version 2.6.18-1.2200.fc5 (brewbuilder@hs20-bc2-3.build.redhat.com) gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 Sat Oct 14 16:59:26 EDT 2006 yum version 2.6.1 How reproducible: I don't want to try again. Steps to Reproduce: 1. See above 2. 3. Actual results: The disk system is a Raid1, so I cannot say that 'the disk drive ate my system', even though it is currently in a degraded condition (another bug story..) I had a recent backup of /etc and also the build directory of the dovecot + lda imap mail system. With the backup /etc, I was able to get the postfix config and the dovecot config as it was before. These are now working fine. I still don't get a complete gnome desktop yet. I have done 'yum install xxx' on many of the packages shown on the list, but apparently not enough of them. Even though nautilus has been installed, I still don't see the desktop icons. This system is part of my infrastructure (firewall, mail) and is not used much for office or development work. I can live without a full desktop fore awhile. Expected results: Erasing a big part of my system was unexpected.. Additional info: I was impressed that the system was pretty robust..
Created attachment 141185 [details] List of dependencies (??) which were erased with openldap
"I clicked the 'Apply' button and after awhile, a dialog box came up saying something about dependencies. I said ok.." Did you read the list? how is yum supposed to know that those packages were any more critical to you than any other?
Some of the items on the Erase list don't have any connection to openldap. Perhaps there is a bug in the yum dependency algorithm. ------- "how is yum supposed to know that those packages were any more critical to you than any other?" 1) A count of packages destined for erasure - above a certain count would trigger another dialog box. How about 6 for a count (as default) 2) Match erasure names with a configurable list. If any match occurs - trigger another dialog box. If Fedora has aspirations for the mass market, serious 'gotcha's need to be smoothed over. Mass erasures by Yum is a gotcha.
pirut 1.2.8 (currently in updatest-testing) has a bit more scariness around this to try to keep people from shooting themselves in the foot. Such things don't belong in the yum command line tool at all, though.
I do think there is a problem with the dependency analysis of yum. 1) My openldap was not configured properly (i.e., was not working) 2) Yet, all (??) of the applications which were purported to be dependent on openldap, were working. This includes subversion, firefox, .. What does 'dependency' mean in this context? (check attached list of erased dependencies - it is strange) Also, in the gui wrapper (add/remove packages), there is a 20 second timeout after the dependency analysis. If no action is taken, the dependencies are erased. So I did not even have to click OK to wipe much of my system! (perhaps this is fixed in the pirut command?).
Created attachment 141600 [details] Complete output of 'yum erase openldap' command. I did a repeat of this problem (pulling out at the last moment with 'N') This is on an FC6 system with updates as of a few days ago. [root@hoho2 ~]# yum erase openldap 2>&1 | tee openldap_erase.out The bottom part of opendap_erase.out is: ... ... usermode i386 1.87-3 installed 516 k usermode-gtk i386 1.87-3 installed 172 k vino i386 2.13.5-4.1 installed 1.1 M wireshark-gnome i386 0.99.4-1.fc6 installed 1.3 M yelp i386 2.16.0-10.fc6 installed 1.9 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 263 Package(s) N Is this ok [y/N]: Exiting on user Command Complete! [root@hoho2 ~]# Attached is the complete openldap_erase.out file It would have erased an impressive part of my system..
Hmm, looks like I should have made the file extention .txt instead of .out
why are you telling us this? There's nothing wrong with the dep processing nor with the removal mechanism. All that's wrong is that it seems like you don't understand how rpm package dependencies work. this is not a bug.
I think I understand how rpm package dependencies work: [root@hoho2 user2]# rpm -q --provides openldap config(openldap) = 2.3.27-4 liblber-2.3.so.0 libldap-2.3.so.0 libldap_r-2.3.so.0 openldap = 2.3.27-4 yum then goes through the installed packages and locates every package that requires any of these. Then yum marks these packages for removal. Then yum loops through the installed packages again and again - looking for more packages that require any of the 'provides' from any of the packages marked for removal. When the list of packages marked for removal remains the same, the loop is exited and the user is shown the final list and asked whether they want them deleted. For example, evolution requires libldap [root@hoho2 user2]# rpm -q --requires evolution | grep libldap libldap-2.3.so.0 However, evolution (for example) will run without openldap installed. At run time, if openldap is available, evolution displays the option to find contacts using openldap. If openldap is not available, it does not display that option for the user to configure. Because evolution optionally uses openldap, why should it be erased when openldap is erased? It seem like there is a bug there somewhere.
b/c it is not optional. Evolution is linked against openldap. It REQUIRES those libs to run. There's no choice in the matter.
I guess the yum/rpm package management is cruder than Debian's aptitude/dpkg See http://www.debian.org/doc/FAQ/ch-pkgtools.en.html Section 7.5 <copy-paste from above link> Similar situations occur when dealing with libraries: generally these get installed since packages containing applications depend on them. When the application-package is purged, the library-package might stay on the system. Or: when the application-package no longer depends upon e.g. libdb4.2, but upon libdb4.3, the libdb4.2 package might stay when the application-package is upgraded. In these cases, `foo-data' doesn't depend on `foo', so when you remove the `foo' package it will not get automatically removed by most package management tools. The same holds true for the library packages. This is necessary to avoid circular dependencies. If you use aptitude (see aptitude, Section 7.1.3) as your package management tool it will, however, track automatically installed packages and remove them when no packages remain that need them in your system. <end of copy-paste> In the case of evolution, it does not depend on the openldap application, only on the libraries: [user1@hoho2 ~]$ rpm -q --requires evolution | grep ldap libldap-2.3.so.0 [user1@hoho2 ~]$ rpm -q --requires evolution | grep lber liblber-2.3.so.0 [user1@hoho2 ~]$ rpm -q --requires evolution | grep openldap [user1@hoho2 ~]$ In Debian, Evolution would not be removed when openldap was removed. This is in contrast to the cascading removes caused by yum/rpm when openldap is removed.
umm. I cannot comment on what dpkg or apt will do in any circumstance. Although the above sounds more like a function of packaging choices and nothing in the package manager.