Bug 457035

Summary: Review Request: libproxy - A library handling all the details of proxy configuration
Product: [Fedora] Fedora Reporter: Nicolas Chauvet (kwizart) <kwizart>
Component: Package ReviewAssignee: Adel Gadllah <adel.gadllah>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: danw, fedora-package-review, jorton, mclasen, nathaniel, notting, rdieter
Target Milestone: ---Flags: adel.gadllah: fedora‑review+
kevin: fedora‑cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-04 21:09:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Nicolas Chauvet (kwizart) 2008-07-29 07:17:18 EDT
Spec URL:
Description: A library handling all the details of proxy configuration

Comment 1 Adel Gadllah 2008-08-02 06:39:46 EDT

[+]	source files match upstream:
[-]	package meets naming and versioning guidelines:
		please use libproxy-python instead of libproxy-binding-python
[+]	specfile is properly named, is cleanly written and uses macros consistently.
[+]	dist tag is present.
[+]	build root is correct.
[+]	license field matches the actual license.
[+]	license is open source-compatible.

[+]	license text included in package.
[+]	latest version is being packaged.
[+]	BuildRequires are proper.
[-]	Requires are proper:
		xulrunner does not use soname's so please add 
		Requires: gecko-libs >= 1.9 to the plugin-mozjs
[+]	compiler flags are appropriate.
[+]	%clean is present.
[+]	package builds in koji:
[+]	package installs properly.
[+]	debuginfo package looks complete.
[+]	rpmlint is silent:
	It isn't:
	libproxy-binding-python.x86_64: W: no-documentation
	libproxy-devel.x86_64: W: no-documentation
	libproxy-plugin-gnome.x86_64: W: no-documentation
	libproxy-plugin-kde.x86_64: W: no-documentation
	libproxy-plugin-mozjs.x86_64: W: no-documentation
	libproxy-plugin-networkmanager.x86_64: W: no-documentation
	8 packages and 0 specfiles checked; 0 errors, 6 warnings.
	But this warnings can be ignored.

[+]	ldconfig is used in %post and %postun
[+]	owns the directories it creates.
[+]	doesn't own any directories it shouldn't.
[+]	no duplicates in %files.
[+]	file permissions are appropriate.
[+]	code, not content.
[+]	documentation is small, so no -docs subpackage is necessary.
[+]	%docs are not necessary for the proper functioning of the package.


Summary & Comments:

1) Please use libproxy-python instead of libproxy-binding-python
1.1) Any reason why the java and C# bindings aren't packaged?
2) Fix the gecko-libs requires
3) Consider submitting the patch to upstream (if not done already).
Comment 2 Adel Gadllah 2008-08-02 06:41:17 EDT
"Requires: gecko-libs >= 1.9" for f9+ 
Comment 3 Nicolas Chauvet (kwizart) 2008-08-04 06:19:05 EDT
Spec URL:
Description: A library handling all the details of proxy configuration

- Rename binding-python to python
- Add Requires: gecko-libs >= %%{gecko_version}
- Fix some descriptions
- Add plugin-webkit package

Patch has been submitted upstream

The java and C# binding aren't present in the source tarball (not ready yet).
Comment 4 Adel Gadllah 2008-08-04 10:22:48 EDT
OK, looks good now.
Comment 5 Nicolas Chauvet (kwizart) 2008-08-06 10:33:17 EDT
New Package CVS Request
Package Name: libproxy
Short Description: A library handling all the details of proxy configuration
Owners: kwizart
Branches: F-8 F-9 EL-5
Cvsextras Commits: yes
Comment 6 Kevin Fenzi 2008-08-06 13:33:21 EDT
cvs done.
Comment 7 Nathaniel McCallum 2008-10-18 23:35:09 EDT
Hi, I'm one of the authors of libproxy.  I'd like to suggest that my preferred method of packaging libproxy is *not* to create separate binary packages for each plugin.  I know this flies in the face of conventional wisdom.  However, libproxy is designed to always do the best with what is given.  If a certain dependency is not met for a plugin, the plugin will simply fail to load.  It will be far more confusing for the user to have all these plugin packages, then for libproxy simply to work for them.

What outstanding issues remain for libproxy to be in Fedora?
Comment 8 Adel Gadllah 2008-10-19 04:55:51 EDT
> What outstanding issues remain for libproxy to be in Fedora?

Nothing, Nicolas has to import and build it...

Comment 9 Nicolas Chauvet (kwizart) 2008-10-20 06:27:37 EDT
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.

Doies it sound good for now ? Do you have other advices ?
Comment 10 Joe Orton 2008-10-20 06:40:09 EDT
Splitting the backend plugin DSOs into separate binary packages seems like the right thing to do:

- each KDE/GNOME/etc DSO must have shared library dependencies on the respective environment libraries
- those library dependencies must be reflected (automatically) in RPM package dependencies
- putting the plugins in the main package would therefore pull in all the necessary dependencies in KDE/GNOME/etc

It might be a good idea to get the -plugins- packages pulled in via some other deps, or simply by updating comps to ensure they get installed by default.

I've updated neon upstream to add support for libproxy, BTW.
Comment 11 Nathaniel McCallum 2008-10-20 09:06:33 EDT
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
3. include the plugins in the main package (but don't add their deps to the rpm)

Again, this is not the standard method, I know.  I'm trying to avoid the following scenario:

1. John installs an app which depends on libproxy
2. Afterwards, John installs firefox.
3. If the mozjs plugin is included in the base libproxy package, WPAD/PAC will *just work*.  However, if mozjs is not in the base libproxy package, John will *also* have to install libproxy-plugin-mozjs to get WPAD/PAC support.

libproxy should always just work, no matter what is installed on the system.

Again, as a packager, I know this flies in the face of conventional packaging wisdom.  However, the user has a lot to gain by doing it this way.

If rpmbuild cannot be told to ignore DSO shlib deps, then I don't see any other solution than one-package-per-plugin.

Great to hear about neon!
Comment 12 Joe Orton 2008-10-20 09:52:54 EDT
It is possible to ignore the automatic shared library deps, but it's Really Really Bad (TM), because you lose the ability to enforce ABI compatibility.

As I mentioned - I think the right thing to do for the example you give would be to have firefox Require the mozjs plugins subpackage, if it's the case that the latter depends on the former.  Everything still works automagically that way.

(It may be necessary to achieve a critical mass of libproxy-enabled apps before there is enough motivation to add these backwards -plugins dependencies)
Comment 13 Nathaniel McCallum 2008-10-20 10:06:37 EDT
There is no ABI compatibility for plugins.  They are considered "internal" to libproxy.  Further, the plugins change with every point release (see the plugins directory).  In short, the "plugins" are not really plugins, but "other files" related to libproxy.
Comment 14 Nicolas Chauvet (kwizart) 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).
Comment 15 Nathaniel McCallum 2008-10-20 10:50:39 EDT
Ok, I understand now.  So we are on the same page, here is a list of the plugins, their dependencies and where there upstream might be...

PLUGIN         | DEPS                 | UPSTREAM
envar          | None                 | libproxy
file           | None                 | libproxy
gnome          | x11, xmu, gconf      | gnome control-center?
kde            | x11, xmu             | libproxy? somewhere in kde?
mozjs          | mozjs                | Firefox?
networkmanager | dbus, NetworkManager | NetworkManager
webkit         | WebKit               | WebKit

Comment 16 Nicolas Chauvet (kwizart) 2008-10-21 08:51:47 EDT
So, maybe there is an in-between:

Spec URL:

Few comments for non-rpm-spec-file-readers:
Anyone can rebuild the libproxy package and use --with mozjs --with networkmanager --with webkit to have missing sub-packages built and installable along with the default set of fedora libproxy packages. (libproxy-bin libproxy-python, libproxy-gnome and libproxy-kde)

I think we should be able to deal with comps.xml for kde and gnome. But I would like advices from the related desktop team.
Comment 17 Nathaniel McCallum 2008-10-27 11:29:35 EDT
Please ignore my packaging nitpicks.  Its far more important (to me) that it is packaged than *how* it is packaged.  Sorry for slowing up the process.
Comment 18 Rex Dieter 2008-10-27 11:46:38 EDT
upstream input, constructive criticism, etc...  is always very welcome.
Comment 19 Nicolas Chauvet (kwizart) 2008-10-27 13:58:05 EDT
Indeed, I would say even that: your advices are not only welcomed, but they are really needed to define with you an sharp way to package libproxy. So this is an exchange in two ways And without your advices, there is low chance that the package will be provided within fedora.
Also, I hope that this talk doesn't only serve Fedora. I've for example requested the OpenSUSE packager for advices, and I know he's following.

So according to the quick advices received from the kde team. It is better to link directly to libproxy library. So I guess to use this spec solely. Now I just wonder if libproxy will be useable as is , since it will lack the related modules from within libproxy along with lack of support from the related components (control-center, neon, NetworkManager, xulrunner,yum , pirut etc), At least for our configuration tools in F-10.

So for the long plan. I expect there is a need for a feature request to have most "internet application" to be converted/tested to libproxy support/compliance.

Spec URL:
Comment 20 Matthias Clasen 2008-11-12 21:06:41 EST
libsoup >= 2.25 adds a libproxy dependency too, so getting this reviewed sooner rather than later would be appreciated from the gnome side, too.
Comment 21 Nicolas Chauvet (kwizart) 2008-11-14 05:34:34 EST
The package itself have been formally approved already. There is still few questions remaining that prevent to import.

So for the gnome side, is there any plan to add libproxy support via Gconf-2 ?
In which case I will import the last version in F-11.
I think a NetworkManager advice would be needed.
Comment 22 Matthias Clasen 2008-11-14 14:27:48 EST
GConf doesn't really enter the picture. NetworkManager should certainly play some role in dynamic network configuration (including proxies). But those things should certainly be developed upstream and do not have any direct bearing on the packaging of libproxy, afaics.
Comment 23 Dan Winship 2008-12-01 12:09:05 EST
(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.
Comment 24 Nathaniel McCallum 2008-12-01 12:41:53 EST
Dan's packaging proposal looks good to me.  Particularly the libproxy-pac virtual dep.  In non-embedded usage, libproxy should always have one of the pac-runner plugins installed (mozjs, webkit, etc).


One thing to point out is that while the NM plugin requires NM for functionality, it doesn't require NM for linkage (it links against dbus).  Not sure if that helps at all.
Comment 25 Nicolas Chauvet (kwizart) 2009-01-22 08:20:57 EST
Sorry for the late answear, I've hit #475283 which prevented me to have a system ready for packaging.

I've implemented the comments from Dan in #23, few notes:
- The main package should be multilibs compliant so I've splitted the bin and python (which are mono-arches) and have them required by the main.
- NetworkManager plugin is merged back in the main package since dbus-libs which it depends on is not much.
- Enabled all plugins by default at build time
- Add virtual Requires on %{name}-pac (EV) which are provided (EVR) by mozjs and webkit. We only requires on Epoch:Version to let open for another package to provides that capability

Spec URL:

I plan to import libproxy to F10 and devel soon; unless that still needs improvements...
Comment 26 Matthias Clasen 2009-01-22 10:48:52 EST
You probably want to consistently use

Requires:       %{name} = %{version}-%{release}

for all subpackages (some miss the release part, currently)

Other than that, it looks great to me.
Comment 27 Nicolas Chauvet (kwizart) 2009-01-22 12:40:34 EST
oups, indeed, fixed the kde and gnome sub-packages.
Comment 28 Fedora Update System 2009-01-23 21:37:10 EST
libproxy-0.2.3-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libproxy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0902
Comment 29 Fedora Update System 2009-02-04 21:09:37 EST
libproxy-0.2.3-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.