Bug 215621

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.