Ticket #370 (closed task: fixed)

Opened 4 years ago

Last modified 4 years ago

allow bundling libiberty

Reported by: till Owned by:
Priority: major Keywords:
Cc: toshio Blocked By:
Blocking:

Description

Proposal topic

libiberty seems to be a library that is intended to be bundled with other software, but it is not on the exception list for bundled libraries: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

Overview

It is currently bundled in binutils and the maintainer is sure that this is the right case: https://bugzilla.redhat.com/show_bug.cgi?id=225615#c15

Problem space

I would like to be able to properly packager other software that contains a libiberty copy.

Solution Overview

Add libiberty to the exception list.

Active Ingredients

Fedora packagers are affected by this change.

Owners

Till Maas

Change History

comment:1 Changed 4 years ago by kevin

  • Keywords writeup added; meeting removed

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

Will see about getting it added to the list.

comment:2 Changed 4 years ago by toshio

  • Cc toshio added

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?

comment:3 Changed 4 years ago by kkofler

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

comment:4 Changed 4 years ago by kevin

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? ;)

comment:5 Changed 4 years ago by ajax

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.

comment:6 Changed 4 years ago by toshio

  • Keywords meeting added; writeup removed

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).

comment:7 follow-up: ↓ 9 Changed 4 years ago by kevin

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

comment:8 Changed 4 years ago by toshio

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.

comment:9 in reply to: ↑ 7 Changed 4 years ago by till

Replying to 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/

comment:10 Changed 4 years ago by ajax

  • Keywords meeting removed

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.

comment:11 Changed 4 years ago by kevin

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

comment:12 Changed 4 years ago by kevin

Any news here?

comment:13 Changed 4 years ago by ajax

  • Keywords meeting added

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

comment:14 Changed 4 years ago by kevin

  • Keywords meeting removed

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.

comment:15 Changed 4 years ago by toshio

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.

comment:16 Changed 4 years ago by toshio

  • Status changed from new to closed
  • Resolution set to fixed

Guidelines have been updated with this.

Note: See TracTickets for help on using tickets.