From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040929

Description of problem:
Consider that, after a fresh install, you attempt to install Livna's
vcdimager, that depends on libiso9660.so.0.  As it turns out,
Fedora.us's libcdio-0.69 offers this shared library, but libcdio-0.70
doesn't any more.  I suppose that's why both packages are still
available from the fedora.us repo for FC2.

Since vcdimager also depends on libcdio.so.0, up2date chooses the
newer version of libcdio first, and then, when it attempts to resolve
the libiso9660.so.0 dependency, it fails, because it never reconsiders
libcdio-0.69.

Unfortunately, up2date -i libcdio-0.69 (or even
libcdio-0.69-specificrelease) doesn't work, presumably because up2date
doesn't try to use 0.69 as the version number.  But when I run up2date
--get libcdio-0.69, it correctly downloads the rpm I want, obviously
without bringing in the needed dependencies to install this package.

up2date --solvedeps libiso9660.so.0 also fails.  libcdio-0.69-*.hdr
never make it to /var/spool/up2date; AFAICT up2date discards it early
as out-of-date.  A bad idea in this case.

Even after I manually install the package, after installing its
dependencies with up2date, up2date will *sometimes* decide that it
wants to update libcdio, and then fail because the library only
provided by the old version of the package isn't provided by any other
package any more.  It seems to happen more frequently when there are
lots of packages to update, e.g., after a daily rawhide push.  If I
--exclude=libcdio to get the other packages updated, it completes the
update and then it won't attempt to update libcdio again.

Version-Release number of selected component (if applicable):
up2date-4.3.40-1

How reproducible:
Always

Steps to Reproduce:
1.Make sure you don't have libcdio already installed
2.up2date -i vcdimager (have livna and fedora.us stable in up2date
sources)
3.up2date --solvedeps libiso9660.so.0
4.up2date -i libcdio-0.69
5.up2date -i libcddb
6.up2date --get libcdio-0.69
7.up2date -i vcdimager

Actual Results:  2 and 3 fail because up2date fails to consider the
older version of libcdio.

4 fails, possibly for the same reason, but possibly because up2date
fails to regard -0.69 as a version number.

5-7 work, but it could be far more cumbersome if libcdio was a package
with a large number of dependencies.

Expected Results:  It would be nice if 2 worked in these conditions
(older library package provides shared library that newer library
package doesn't, but that is still needed), but having working 3
and/or 4 might be good enough.

Additional info:

In case by the time you get to this the packages no longer trigger the
problem, here's a scenario that should be easy to create artificially:

package foo-1 provides foo1, package foo-2 doesn't
package bar requires foo1

Have the 3 packages in the same yum repository, and try to install bar.