Dear Seth and other yumsters, I'm grooming my laptop to make room for RH 9 sometime today (which seems to want to install bigger, can't imagine why:-) and am using yum remove an yum list and yum info a fair bit. While doing removals, one encounters the usual dependency resolution problem that yum addresses in installs, but in the other direction where it is conceivably even more difficult. It is easy to add packages to satisfy dependencies -- it is REALLY HARD to disentangle packages for safe removal. Here yum is a bit more easily confused and doesn't seem to always want to do the right thing. For example, I don't use ldap at all (and put it on the laptop originally in case I ever wanted to play with it) so I try e.g. yum remove openldap\*. Yum resolves the dependencies and reports that: "package nfs-utils needs /sbin/nologin (not provided)" and quits. This is very confusing, as a) /sbin/nologin is in util-linux and has nothing obvious to do with any component of openldap and b) nfs-utils doesn't have any obvious interdependency on ldap. Is it safe to force a removal of openldap with e.g. rpm --erase? Hard to tell -- if some craziness in the removal process caused /sbin/nologin to be removed, that would be at least moderately unfortunate (although since I'm going to upgrade I'll probably force the issue expecting the upgrade to "fix" it). I also don't know if I'm seeing the ONLY dependency problem or just the first -- if I cleared or ignored THIS problem, would there be twenty more that just weren't reported for brevity's sake? Then there is the "odd little package" problem. For example, not to pick on Tk or anything, let's pick tix (and even the rest of Tk). I don't use Tk any more, and never expect to. I consider it solidly obsoleted by Gtk, and loathe tcl (which I'd probably keep only because it is connected to expect, which is otherwise pretty cool). So I'd LIKE to figure out if I can remove Tk, or even an unused component of Tk like tix, safely. To mangae these two cases, I really need to see the full "dependency tree" for the packages involved -- the actual data yum/anaconda/whatever extracts to determine what depends on what and where. I therefore would like to request: yum depends packagename which basically creates a list of all packages that depend ON packagename as well as a list of all packages that packagename depends on. It should probably take the "installed" option so that it can be restricted to just installed packages, or perhaps use installed as the default (it would be the most common usage anyway) and add an option for doing the entire repository, or union of repositories. Several other arguments occur to me. -d depth might control the backward depth of the dependency tree generated, as one might not care to know BOTH the backward and forward dependencies of the dependencies themselves -- or one might. -f might cause the specific files that are required from each dependency to be also listed (just as at least one is in a yum remove now). With -c for conflict a conflict resolution tree for removal might be generated. Such a tree would show both "essential" dependencies -- packages either way that are unique sources for key files -- and what I'd really call "broken" or "resolvable" dependences -- places where the usual dependency resolution cycle is showing a conflict with a file like /sbin/nologin (for reasons that escape me, since nothing in any of the openldap packages visibly connect with this file, so I cannot see why removing openldap would affect it in any way) that clearly is either an error or a weirdness in the hidden dependency tree. Finally, I think that this would be a really useful diagnostic tool to have around anyway. One of the most difficult things, I'm sure, about grooming a repository for public usage by "dummies" is the need to work out dependency resolution so conflicts basically don't ever happen, and can be resolved sanely where they do anyway (as they will). Currently, I imagine that this is fairly difficult and largely occult except to experts. It would be lovely for yum -d 3 depends packagename to produce a report that could go straight to bugzilla or the rather notorious developers of certain rpm's that, ahem, seem to tie knots out of dependency loops. Things like the old sendmail conflict (where sendmail had to be included even if one wished to use e.g. postfix) would be openly illuminated and MUCH easier to fix in the future. As a side effect of this, one could likely make "yum remove" handle removal of odd case packages like openldap that perhaps overlap and conflict with another package in an ignorable way for a key executable. In the more complex cases where there really are multiple packages that provide the same required file and where both are installed on the system but a remove isn't permitted because it would remove (only) one of them, needed by other things you AREN'T removing, it would also be lovely to have a "repair" function that is smart enough to effectively run yum provides on the conflicted file, determine alternative packages that can provide it, and either arrange for an install or forced update of a selected providing package after removal (to ensure that the missing package is replaced, this time "provided by" the correct source) or go ahead and run the remove anyway if rpm itself is smart enough not to remove files "belonging" to multiple packages or it is really safe to do so. Or am I being very silly and does yum already do all of this? rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
