2010/6/17 Ian Weller <ian(a)ianweller.org>:
Presently, libproxy bundles libmodman and includes it in the
package.
Upstream split libmodman into a separate tarball, and then set up
libproxy to build off of a system version of libmodman if it exists
(otherwise it uses the version that is bundled with it).
Review request for the new libmodman package:
https://bugzilla.redhat.com/show_bug.cgi?id=603514
The packager will be sponsored by me, but I'm waiting for this package
to go through.
He also submitted this bug against libproxy:
https://bugzilla.redhat.com/show_bug.cgi?id=603517
Which asks the maintainer to upgrade to the version that can optionally
use the system version of libmodman.
And, of course, libmodman conflicts with all previous versions of
libproxy, because there are file conflicts.
Since both of these items basically depend on each other, where should
we go next?
I guess there is a circle dependency here.
You need to review libmodman and verify the libproxy can build with
your own build in mock (as we don't support chain build in scratch
mode for koji). That will be the usability test for libmodman's
review.
Then libproxy can be tested and updated in rawhide.
Remember that since there is an ABI change from F-13's libproxy, and
that this library is in the cirtical path, there is no plan to update
it in F-13...
You can go ahead with libmodman review, and nathaniel sponsorship...
Nicolas (kwizart)