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

[bugzilla at redhat.com]

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


Dan Winship <dwinship at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dwinship at redhat.com




--- Comment #23 from Dan Winship <dwinship at redhat.com>  2008-12-01 12:09:05 EDT ---
(In reply to comment #9)
> 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 ?

You're misunderstanding what the plugins do: libproxy-gnome is not "code to
make GNOME applications use libproxy", it's "code to make libproxy-using apps
have access to the GNOME Control Center proxy settings". That is, if
libproxy-gnome is installed, then when vlc calls
px_proxy_factory_get_proxies(), libproxy will check GConf to see if the user
has configured a proxy in the GNOME Control Center, and if so, it will return
that proxy info to vlc. If libproxy-gnome is NOT installed, then libproxy won't
return GNOME Control Center proxy info to *any* applications, even GNOME-based
ones, because it no longer knows how to look that information up.

Likewise, libproxy-mozjs is not "libproxy support for mozilla-based apps", it's
"PAC/WPAD support for *all* libproxy-using applications, by using mozjs to run
the PAC file". So making firefox depend on libproxy-mozjs would be completely
backwards, and also useless, since firefox doesn't use libproxy.

So, the way the packaging should work is IMHO something like:

    - The mozjs plugin should *always* be installed if libproxy is
      installed, to provide PAC and WPAD support to libproxy-using apps.
      (Maybe some weird environments would rather use the webkit plugin
      rather than the mozjs plugin... perhaps the two plugins could each
      virtually provide "libproxy-pac", and the base libproxy package
      would require libproxy-pac. Or maybe suggests/recommends or whatever
      it's called, to allow people to uninstall it if they really don't
      need it)

    - libproxy-gnome should be part of the GNOME Desktop package set,
      and perhaps also be an explicit dep of any GNOME packages that use
      libproxy (to ensure that they don't end up regressing in behavior
      by losing gconf proxy support).

    - likewise with s/gnome/kde/g

    - Not totally sure about how to organize the deps on the NM plugin...
      since NM is basically a requirement these days, maybe it could just
      be left in the base libproxy package and libproxy would have a hard
      requirement on NM.

-- 
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.