libproxy bundles libmodman, upstream splits into two projects. what now?

[Nicolas Chauvet]

2010/6/17 Ian Weller <ian at 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)