An exception was granted in the 2010-05-04 meeting.

Will see about getting it added to the list.

Just a cup'a'three notes:

1) I'm no longer automatically CC'd automatically to all fesco tickets so it would be great if you could CC at least me (possibly the other FPC members... spot and tibbs were cc'd in the past) to static library tickets that would help me stay informed when something needs to be evaluated and potential ways in which the Guidelines can be improved with ne classifications of things that should be allowed.

2) It was noted in the meeting that one of the reasons for this decision was that upstream recommends bundling. This should never be used as justification. For instance, the mono project recommends bundling of libraries that do not have a stable API to people developing mono apps. We've consistently said no to this.

3) I can add libiberty to the exception list. What is the rationale that I should put with it?

Ad 2, that's what I said too, but nobody listened to me.

Sadly I was dealing with a dayjob issue and was not involved in this decision at all. ;(

1) understood, sorry. ;(

2) I agree personally.

3) Can one of the 5 fesco folks who voted for the expception add a rationale here pretty please? ;)

So, as far as rationale goes, here's my stance. I think this is pretty representative of the other people who voted for the exception; if it's not, please chime in.

a) C copy-libraries (which is a term I just invented to refer to things like libiberty and gnulib) are sui generis; they're not like copy-libraries in languages like Java. Interpreted languages with a module or library system tend to have no real concept of static linkage, in the sense that C or other compiled languages do.

b) Transforming a C copylib into a shared lib is not a fire and forget effort. The library soname is basically invented out of whole cloth in that case. We don't have any consistent policy for how to choose the soname, nor do we want to invent one that the upstream itself might later adopt should they finally see the light. Such a policy might be desirable, but until we have such a policy we can't act on it.

c) Given a soname policy for this case, the library maintainer then needs to monitor the shared lib for ABI changes and change the soname to match, so that library consumers are properly updated; and would also need to monitor other packages for using the copylib version instead of the shared version. As we'd be creating the library ex nihilo, we'd need to find a maintainer, and then get them to accept this additional maintenance burden. We don't have any tooling for doing so, nor any real precedent for it. Java library owners, for example, are not expected to monitor other packages for copy inclusion of their libraries (as far as I'm aware). Again: such a policy and practice might be desirable, but that's not currently at issue.

d) libiberty just isn't used anywhere else. It lives in binutils-devel, but the only thing in F12 that BuildRequires binutils-devel is binutils itself. It should probably be moved to a -static subpackage, but that's about it.

e) The GNU project - libiberty's upstream - is not about to change their minds about the proper consumption of libiberty. This doesn't mean they're not wrong; but it does mean we'd be wilfully diverging from upstream for no practical benefit (since, as per point d, there's no real sharing to be done).

So in short, forcing a shared libiberty would be more work and divergence from upstream for no practical benefit. If someone wants to go tilt at the GNU windmill to fix it, that'd be lovely, but I'm not holding my breath.

So... those are all good reasons but for a different type of problem. They fit with our current Static Library Guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries I believe that even if they're not explicitly stated there, the reasons given above will all allow for static linking without a vote by FESCo.

This ticket was opened to address bundling of libiberty code in other upstream applications (the reason that only binutils requires binutils-devel appears to be because libiberty is being bundled in the other apps). Putting back onto the meeting agenda to get a vote on bundling rather than static linkage and to get rationale for the exception (if granted).

This ticket was tabled for another week to allow Ajax to look into how many packages we have that bundle this and why.

btw, if someone thinks that libiberty and libegg set a pattern that they can extract into a document and should be allowed in the Guidelines then feel free to write it up and I'll help to clarify it to the point that we can get it before FPC for a vote.

Replying to [comment:7 kevin]:

This ticket was tabled for another week to allow Ajax to look into how many packages we have that bundle this and why.

Btw. this is the software not yet in Fedora that also bundles libiberty, which is what made me aware of the issue:
http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/

Removing from meeting for this week. I got knocked out by a broken arm on Thursday, so I've not had time to finish the scan and report.

Any chance we could add this to tomorrow's meeting? Or should we push it off a bit more?

Any news here?

24 packages bundle it as of F13. I'll have an update for the meeting next week.

AGREED: libiberty, gnulib, and libegg are not libraries. They are exempt from the library bundling clause. (nirik, 20:18:02)

Leaving ticket open pending some write up.

Here's my initial draft:

https://fedoraproject.org/wiki/Bundled_Library_Packaging_Draft

There's a packaging committee meeting tomorrow (don't know if we'll achieve quorum... I think we had four replies that they'll be there). So... if you have changes you'd like to see, please mention them to me before then just in case.

Guidelines have been updated with this.