[Bug 457035] Review Request: libproxy - A library handling all the details of proxy configuration

bugzilla at redhat.com bugzilla at redhat.com
Mon Oct 20 10:27:38 UTC 2008


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 at gmail.com>  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.




More information about the package-review mailing list