I can't figure out any way to make this justification work with the current theory behind unbundling libraries. For instance, the mono and java worlds have pretty much this same outlook towards the libraries that they're bundling and we've strenuously said no to this in the past. I see three immediate options:

1. We tell fesco, this justification violates the reasoning behind requiring unbundling of libraries, that we recommend that they do not approve an exception for this, and that they need to review this again in that light (If we do this, I would propose that the library in question be shipped as a private library in its own package -- thus unbundled but in a way that makes it less likely to be used by many projects.)
2. We let fesco know that this is really exceptional and we won't update the guidelines for it other than to note that there is an exception for this. If we do this, I'd say that the exception should specify the following three things: The specific application, the specific library, and a timeframe (for instance, if the library is not unbundled by F16, the library needs to be shipped as a private library in its own package.)
3. We rethink the restriction on bundled libraries. We can mark packages that carry bundled libraries with the virtual provides that we specified in the updated draft. So the problems with bundled libraries are reduced a bit. Here's what I see as the remaining bundled library issues:

• If the library in question is used by multiple applications, we'd need to update in multiple places.
• If the library is forked, we have to update the patches that have been applied by the application to the new version of the library as we update to the new version of code.

One Guideline issue is that we don't have guidance on how the bundled library relates to the upstream for that library. For instance, if a new version of the upstream library is released, do we require that the application bundling the library updates immediately? In rawhide? Not at all? The issue with not updating is that if we need to upgrade for a time-critical reason (for instance, security) later, we'll have to fix any incompatible changes at that time. OTOH, updating the bundled library whenever upstream updates means that we'll be requiring package maintainers to do much more work on maintaining the code in question -- tracking both upstreams, making patches to keep the package working with the latest versions, etc.

nirik/kevin asked on irc if fpc would like to move deciding on exceptions to something that the fpc handles. I think it's just a question of looking for options, not a request from fesco to do so. So something to consider and if we're willing just let nirik know that it is an option.

Thought of a way this might fit in:

If upstream for gst-convenience and gupnp-dlna are the same we might be able to craft some sort of policy about that. The reasoning would be along the lines that the gupnp-dlna tarball could be considered canonical for gst-convenience due to the upstream being the same. The separate source repository is just there to aid upstream in moving the canonical location from gupnp-dlna into gstreamer itself.

CC'ing Peter Robinson to find out if this is true so that we know that this is the direction we should pursue.

One note about this that's a bit tricky -- if some third party started using gst-convenience despite gst-convenience's upstream saying that the API is unstable we'd need to start packaging the library for use by multiple packages as the alternative is maintaining the library in multiple packages in a bundled state (exactly what we want to avoid). This is something we should probably diplomatically make everyone aware of.

pbrobinson says that the upstreams are different so we're back to the three choices I outlined in the beginning.

We ran out of time at this meeting. Will look again next meeting.

fesco also voted to allow xulrunner to bundle libvpx. It really doesn't help us build a community of packagers if we seem to make some some packages more equal than others without being able to articulate a technical reason for why they're better. If we can pass it, I think we should vote to allow software to bundle libraries with the proper provides. If we think that this is a major enough problem that we can't discard the rule in the general case then I guess we need to come up with a plan for addressing how to overrule fesco on these.

Replying to [comment:7 toshio]:

fesco also voted to allow xulrunner to bundle libvpx.
Sigh, they hardly could have done worse.

It really doesn't help us build a community of packagers if we seem to make some some
packages more equal than others without being able to articulate a technical reason for why
they're better.
We will never be able to do so, because bundled libs will alway render the situation worse (avoidable distro size bloat, avoidable dependencies, duplicated bugs, duplicated risks, ...)

If we can pass it, I think we should vote to allow software to bundle libraries with
the proper provides.
I do not agree. IMO, bundled libs should always remain a rare, special exception and require explicit special permission of FESCO.

If we think that this is a major enough problem that we can't discard the rule in the general
case then I guess we need to come up with a plan for addressing how to overrule fesco on these.
ACK. May-be, this FESCO and the people endorsing bundled libs need to go through a learning curve to understand the harmful nature of their decisions - Let's hope a critical security breach or malfunction inside of one these bundled+unbundled libs will cause major churn and demonstrate the defectiveness of "bundled libs" in near future.

Nirik will ask FESCo if they want the FPC to handle these exceptions.

fesco hasn't looked at the fpc handling exceptions yet, we can continue to discuss the other options, though.

Okay, FPC is now in charge of these and we now have a more fleshed out set of standard questions to help guide the discussion:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

Additionally, I've thought of a new angle where things like this could fall -- Allow bundling of libraries where the required functionality is in the library's upstream just not released yet. This would allow quite a few things in, I think, which is both good and bad. If we did that, we'd very likely want to have the standard questions regarding timeline answered so that we could check back on it and make sure the library was no longer bundled in case the maintainer disappeared or got busy with something else.

https://fedorahosted.org/fpc/ticket/33

If you don't think gupnp-dlna would fall under this exception, please let me know.

Replying to [comment:12 toshio]:

https://fedorahosted.org/fpc/ticket/33

If you don't think gupnp-dlna would fall under this exception, please let me know.

I think it should mostly fit into that category.

Okay, https://fedorahosted.org/fpc/ticket/33 passed today. I think we just want to have some sort of rough timeline of when the upstreams plan on getting the functionality into gstreamer and gupnp-dlna will unbundle. We can then revisit this issue then and either close it if it's now unbundled or decide whether merging the functionality has stalled and we need A) more time or B) to find an alternative.

This is no longer bundled in rawhide. Thanks, probinson for tracking this through to its conclusion.