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
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
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
Version-Release number of selected component (if applicable):
The system is an updated FC5, but probably the problem could also happen with FC6.
Linux version 2.6.18-1.2200.fc5 (email@example.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
I don't want to try again.
Steps to Reproduce:
1. See above
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.
Erasing a big part of my system was unexpected..
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
Install 0 Package(s)
Update 0 Package(s)
Remove 263 Package(s)
Is this ok [y/N]: Exiting on user Command
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
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
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
For example, evolution requires libldap
[root@hoho2 user2]# rpm -q --requires evolution | grep libldap
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
[user1@hoho2 ~]$ rpm -q --requires evolution | grep lber
[user1@hoho2 ~]$ rpm -q --requires evolution | grep openldap
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
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