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 #9 from Nicolas Chauvet (kwizart) <kwizart@xxxxxxxxx> 2008-10-20 06:27:37 EDT --- @Nathaniel Thx for your advices. The problem to have libproxy packaged as one whole is that dependencies from each modules will need to be satisfied. And the dependencies will be huge if we need to satisfy libproxy-gnome on a KDE system, for example (or even on a X-less system). So libproxy is using dlopen for the modules, which is usually a good thing. But it shoudn't prevent the code from beeing reviewed by the related project. (either NetworkManager, gnome, kde, mozilla, etc). That way, only the libproxy dependency will be added if the package was compiled with libproxy support. That's what I don't understand whith the current libproxy scheme: In the vlc case, the code to support libproxy has been added (it mean, reviewed by the VideoLan team) to the vlc source code. So I cannot understand why it is not the same with NetworkManager Gnome mozilla and etc ? The problem I could expect is that it will change the behaviour to the related application. So for now I would only import the libproxy package. Without anything else (no plugins) And warn the different applications to add support for libproxy by themselves. For the libproxy-bin. The split is needed for multilibs compliance If any application needs this binary, it will need to requires it. @Nathaniel Doies it sound good for now ? Do you have other advices ? -- 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@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review