[Yum] Hmmm, an actual new feature request...

Robert G. Brown rgb at phy.duke.edu
Wed May 21 14:41:30 UTC 2003


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 at phy.duke.edu






More information about the Yum mailing list