2010/6/17 Ian Weller <ian@xxxxxxxxxxxxx>: > 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) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
