the --solvedeps stuff seems to work well enough for packages it knows about,
but the resulting output for unknown packages is a bit odd
[root@bp6 up2date_client]# up2date --solvedeps kernelx
No interactive mode available
Please specify either -l, -u, --nox, or package names as command line arguments.
Usage: up2date [OPTIONS] <packages>
--configure graphically configure Update Agent options
-d, --download download packages only, even if configuration
says to install
--src Download src packages as well as binary rpms
--nosrc Do not download src packages (overrides config
setting if set)
--dbpath=<dir> Specify a path where an alternate rpm db is found
-f, --force Force package installation, overriding package
and file skip list
-i, --install install packages, even if configuration says to
--justdb Only add packages to database, do not install to
-l, --list list packages available for retrieval
-h, --help this help screen
-?, --usage Briefly describe the options
-k, --packagedir=STRING colon separated path of directories to look in
--nosig do not use GPG to check package signatures
--nox do not attempt to use X
-p, --packages update packages associated with this System
Profile on Red Hat Network
--showall List all packages available for download
--solvedeps=<deps> finds, downloads, and installs the packages
needed to solve the list of deps
--tmpdir=<directory> where to store temporary files / RPMs
-u, --update update system with all relevant packages
--version show program version information
-v, --verbose Show additional output
--show-channels Show the channel names along with the package
name where approriate
--whatprovides=<deps> shows the packages which solve the comma
separated list of deps
--channel=STRING Specify which channels to use by channel label
--nodownload Do not download packages at all. For testing
yeah, that all needs to be written to be sane. The current arg parsing
code base is pretty out of hand already.
I should be able to fix it for the next major release.
How about if if cant find any solutions for those deps it prints:
No packages were found that satisfy those dependencies.
Sound like expected behaviour?
sounds good to me - could the error line list the deps in the ilst that couldn't get
satisfied, though? I think if pushed up to whatprovides() it'd also handle cases where
unknown deps are just ignored by --whatprovides
jmm@bp6:/home/jmm> sudo up2date --whatprovides=kernelxxx
jmm@bp6:/home/jmm> sudo up2date --whatprovides=kernel,kernelxxx,kernel-headers
so if whatprovides() can do the required print/log/whatever'ing so that unsolvable
deps get spit back to the user, then we're all set (well, solvedeps still needs to
act sane, of course :)
whatprovides() silently ignoring unsolvable deps is made more obvious with
the above barfing on the unsolvable dep (original report here) but as soon as
a solvable dep is also in the list, we're "fine"
jmm@bp6:/usr/share/rhn/up2date_client> sudo up2date --solvedeps=kernel,kernelx
Retrieving list of all available packages...
Removing installed packages from list of updates...
Removing packages with files not specified from list...
There are no packages available for update.
None of the packages you requested were found, or they are already updated.
which makes me think that (aside from notifying of specific unsolvable deps)
we may need to just exit if there's nothing coming back from whatprovides
--- wrapper.py.orig Mon Mar 25 18:48:16 2002
+++ wrapper.py Mon Mar 25 18:47:51 2002
@@ -374,6 +374,8 @@
extraPackages = whatprovides(argObj.getLong("solvedeps"), 1)
pkgNames = pkgNames + extraPackages
channels = up2date.loginInfo['X-RHN-Auth-Channels']
but I'm not sure how that affects expected behavior elsewhere
The bit of patch is basically exactly what I did.
The other more sophisticated logic cases may have to
wait for a redesign. Better handling of the many
varied cases of "sort of failures" is on the plan
for the next major version. It's kind of up
there with "generic handling for special cases"
the above fix should be in 2.7.63 or so (fixed
in cvs already)
I'm gonna flag this one as closed with RAWHIDE as the status.
The more elaborate behaviour would make a good RFE.