Spec URL: http://kwizart.fedorapeople.org/SPECS/libproxy.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/libproxy-0.2.3-1.fc8.kwizart.src.rpm Description: A library handling all the details of proxy configuration http://koji.fedoraproject.org/koji/taskinfo?taskID=745038
Review ============= [+] source files match upstream: 2b2b00a179740548035a1145bbae600db9b0a2ce [-] 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 package. [+] compiler flags are appropriate. [+] %clean is present. [+] package builds in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=745038 [+] 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).
"Requires: gecko-libs >= 1.9" for f9+
Spec URL: http://kwizart.fedorapeople.org/SPECS/libproxy.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/libproxy-0.2.3-2.fc8.kwizart.src.rpm Description: A library handling all the details of proxy configuration Changelog - Rename binding-python to python - Add Requires: gecko-libs >= %%{gecko_version} - Fix some descriptions - Add plugin-webkit package Patch has been submitted upstream http://code.google.com/p/libproxy/issues/detail?id=5 The java and C# binding aren't present in the source tarball (not ready yet).
OK, looks good now.
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
cvs done.
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?
> What outstanding issues remain for libproxy to be in Fedora? Nothing, Nicolas has to import and build it... ping?
@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 ?
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.
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!
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)
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.
(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).
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 Thoughts?
So, maybe there is an in-between: Spec URL: http://kwizart.fedorapeople.org/SPECS/libproxy.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/libproxy-0.2.3-6.fc8.kwizart.src.rpm 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.
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.
upstream input, constructive criticism, etc... is always very welcome.
@Nathaniel 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: http://kwizart.fedorapeople.org/SPECS/libproxy.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/libproxy-0.2.3-7.fc8.kwizart.src.rpm
libsoup >= 2.25 adds a libproxy dependency too, so getting this reviewed sooner rather than later would be appreciated from the gnome side, too.
@Matthias. 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.
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.
(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.
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). +1 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.
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: http://kwizart.fedorapeople.org/SPECS/libproxy.spec SRPM URL: http://kwizart.fedorapeople.org/SRPMS/libproxy-0.2.3-8.fc10.src.rpm I plan to import libproxy to F10 and devel soon; unless that still needs improvements...
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.
oups, indeed, fixed the kde and gnome sub-packages.
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
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.