Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=457035 --- Comment #14 from Nicolas Chauvet (kwizart) <[EMAIL PROTECTED]> 2008-10-20 10:15:17 EDT --- (In reply to comment #11) > Basically, the idea is this: > 1. set the build deps so that all plugins are built > 2. tell rpmbuild to ignore the dependencies in the plugins Here we stop! That's perfectly possible to have rpm to ignore Dynamic Shared Object Dependencies, the question isn't here. Here is the case corner: libproxy is built with all the current dependencies for plugins (let's mention NetworkManager or mozjs and etc). Later NetworkManager or mozjs are updated but with an incompatible ABI. In This case, the interface with libproxy will collapse, unless libproxy is rebuild (for all the dependencies.) On the contrary, when vlc will be updated from 0.9.x to 1.0.x, the ABI with libproxy will be preserved. (and then vlc can even be downgraded from 1.0.x to 0.9.x on specifics needs for end-users ; without even thinking of untracked dependencies). So the perfect answear we can do from the point 2. is: "Don't even think about it!" Now there are two ways I can see for having libproxy packaged. - Split the package with all plugins. (specifically thoses that have special dependencies ). Thus it will lead to use comps.xml so the -gnome package will be installed by default once the "Gnome Desktop Env." group is selected. - Move the code from libproxy-%{project}, to the %{project} itself. (the preferred Method, IMO). This can avoid to have unexpected behaviours unknown from the related $project developpers. Then we could even consider libproxy to be available in /lib(64) instead of /usr/lib(64). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
