gnome-volume-control is pulled in by our existing packages control-center, gnome-settings-daemon and gnome-shell as a Git submodule. It's also being used by budgie-desktop, currently [https://bugzilla.redhat.com/show_bug.cgi?id=1170875 undergoing review].
Per [https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs the copylibs section] of the packaging policy, I'm therefore requesting that we determine whether g-v-c is considered a copylib. If such, we'd then need to patch the packages above to include the Provides: bundled(gnome-volume-control) virtual dependency.
Provides: bundled(gnome-volume-control)
If gnome-volume-control is not considered an appropriate copylib we'd then have to decide how to release it as a shared library and then compile the affected packages against it.
Correction: libgnome-volume-control, not gnome-volume-control
Git repo: https://git.gnome.org/browse/libgnome-volume-control Git commits where it starts getting pulled into Gnome components:
Upstream does not provide a stable api [1]. Consumers of this package (gnome, cinnamon, and now budgie-desktop) are supposed to stick to a specific git version and update at leisure.
[1] https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00003.html
We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-11/fpc.2014-12-11-17.01.txt) and given the size of the code base this seems much too big for a copy-lib.
...making it a static library though should be trivial, and hopefully upstream will think again about making it a real shared library.
gnome upstream (who are also gnome Fedora packagers) are opposed to the change: {{{ The whole goal of using a git submodule is so that we don't offer to 3rd-parties a library, and so that we can change the API without any problems. Using a static library offers all the disadvantages and none of the advantages of using a git submodule.
So it won't be changed upstream, or downstream. }}} [Full discussion is at https://lists.fedoraproject.org/pipermail/devel/2014-December/205428.html and https://lists.fedoraproject.org/pipermail/devel/2014-December/205060.html]
We are in a situation in which there are essentially two users of the module (gnome, which uses the module in three places but is usually updated in lock-step, and now budgie). I also mentioned cinnamon before, but it uses a modified copy (changed artwork, icons, etc), so cannot be unbundled, and is irrelevant for this discussion. Gnome is uninterested in splitting it out, and I understand Bastian's point of view. For him, it would be additional work (change to the build system, new fedora package to create, review and maintain, a change of procedures) without any benefit for Gnome upstream or users. The only real difference would be if the module was converted to a shared library, but this isn't going to happen as long as there's no stable api. For budgie, bundling through a git submodule is also slightly more convenient. Even if there's some important update to libgnome-volume-control upstream, doing a git submodule update is trivial. The only difference between bundling and a static library is in the way that a rebuild after an update is done.
While I'm very much opposed to bundling, and have worked on unbundling a bunch of stuff (mathjax, blosc, jquery which is in progress, minizip, and some other java crap) I think that in this case the benefits are just not worth it: upstream is opposed, there are ~2 users, the library in question is not important for security, and bundling is done cleanly through a git submodule. In the light of this, I ask FPC to reconsider the decision.
@hadess, please ack that my description of your position is factually correct or clarify.
Also, I think that current resolution is unfair towards the (potential) budgie-desktop maintainer. He has no control over gnome packaging decisions, so if FPC really wants to have the thing unbundled, it should request gnome to unbundle the submodule from the three packages. Meanwhile, a temporary exception should be provided for budgie-desktop, so that it can be packaged and tested before F22 alpha. I'm sure that if the submodule became available as a shared or static library, budgie-desktop can be updated to make use of it without any trouble. Current resolution will result in budgie-desktop being rejected/indefinetely-postponed from Fedora, without actually causing any unbundling to happen.
libgnome-volume-control isn't a library. It's a GLib-ish interface to PulseAudio. It doesn't do any IO except through pulseaudio libraries, and it never had any security issues, and I don't see any security issues arising in the future (see below).
libgnome-volume-control's code comes from gnome-control-center's sound panel. libgnome-volume-control is stable, in that it doesn't have bugs very often, and, any changes would be feature-based. We would often modify libgnome-volume-control to add new features for the Sound panel, breaking API in the process. The way git sub-modules are handled, we wouldn't need to update gnome-settings-daemon or gnome-shell as we wouldn't need those new features.
I could copy/paste between those modules, and Fedora's "unbundling" rule would take hold, it's not a "de-duplication" rule. That goes for a number of other copy/paste files (or git sub-modules) between GNOME's core components.
I'll bargain and say that I'll send out my apologies and split out libgnome-volume-control's module into a library the day a security issue crops up.
For him, it would be additional work without any benefit for Gnome upstream or users
Yeh, it's almost as if packaging something for Fedora isn't just a dumping ground for whatever you feel like doing so sometimes you have to do extra work.
The only difference between bundling and a static library is in the way that a rebuild after an update is done.
This is not true. The FPC is much more accepting of random no-real-API static libraries then making everything a copylib.
The way git sub-modules are handled, we wouldn't need to update gnome-settings-daemon or gnome-shell as we wouldn't need those new features.
Indeed, that's the way bundling works ... people can easily randomly update only some of the bundles, which is one of the reasons why the FPC is more accepting of static libs. where that kind of mess can't happen.
and I don't see any security issues arising in the future
Cool, it's good to know that any bugs in your code are ones you knew would be there but just didn't bother fixing.
Cool, and next time someone else wants to ignore some other random part of the policy maybe they'll give us all an apple and they'll think about complying after they've broken 8 other applications ... maybe that's too much effort though, should probably be double figures at least.
In the light of this, I ask FPC to reconsider the decision.
I'll add it to the meeting, "Please reconsider, because nobody can be bothered doing the work" ... I'm guessing it'll pass easily now.
This will be discussed at today's FPC meeting, right? It's past midnight my time but I'll make sure to attend.
To keep the discussion focused, let's try and map out the possible options: a) FPC rejects proposal 1) existing Gnome packages are grandfathered in and don't need to change 2) what happens if a new Gnome module relies on libg-v-c the same way? b) FPC approves bundling 1) Budgie can go in, existing Gnome packages patched to declare bundling (Build can wait until there's another reason to push an update so as to not burden users) 2) existing Gnome packages grandfathered, don't need to declare bundling c) ... ? 2)
We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-15/fpc.2015-01-15-17.00.txt):
Metadata Update from @zbyszek: - Issue assigned to james
Login to comment on this ticket.