If other items in Fedora like gdb are using these libraries, won't removing them cause issues?

Note that API stability alone is not sufficient to make a library bundled. You can take a look at https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries for some ideas about how you can bring out the aspects of binutils and these libraries that you think make it extraordinary.

Links for where this was discussed before as well as libiberty which was a similar case::

• https://fedorahosted.org/fpc/ticket/43
• https://fedorahosted.org/fpc/ticket/63
• https://fedorahosted.org/fesco/ticket/370

None of which is really satisfactory... Sounds like we might want to expand the copylib case to cover this... alternately, this might get denied... no promises yet. Additional information (which might help to decide why/whether this is a copylib) would help. Once again, take a look at the No_Bundled_libraries page for some questions that you could answer that might help with that.

Hi Guys,

If other items in Fedora like gdb are using these libraries, won't removing them cause issues?

Yes. In theory though, if the binutils libraries should be treated as copylibs, then projects that currently link against the shared versions ought to be changed.

GDB itself would not be affected as it already includes its own copy of the binutils library sources.

Note that API stability alone is not sufficient to make a library bundled. You can take
a look at https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

The best match is the Copylibs exception. The binutils libraries were never designed with export in mind, which is why their ABI is unstable. Instead the original intention was just that the libraries would only be used within the binutils project itself, for the tools that make up the binutils suite.

If the copylib excveption is denied, then I am OK with that. The only problem then would be - where should the additional files necessary to build against the binutils libraries be placed. (See https://bugzilla.redhat.com/show_bug.cgi?id=702648 for a list of the potential files). The header files should be straight forward. Bit what about configure scripts and m4 macros ?

Cheers
Nick

Projects from the same upstream source as binutils (sourceware.org) may treat the binutils libraries as copylibs. (+1:8, 0:0, -1:0)

Looks like this exception can cover https://fedorahosted.org/fpc/ticket/43 as well?

For the writeup, I've added the following to

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

"""
binutils libraries (bfd, opcodes)

bundled(binutils)

If the package in question has the same upstream as binutils (sourceware.org), they may bundle binutils. This is because the libraries are developed by the application authors as common functionality shared between several applications. Being developers of both, they'll be intimately aware of both issues that arise in the libraries and know how to port to newer versions of the library as needed.
"""

There's a few questions about this before announcing, though:

• Are those all the libraries? the gdb ticket mentions bfd cpu opcodes libdecnumber libiberty and gnulib. libiberty and gnulib are mentioned earlier although this exception language is both more strict and more informative. libcpu is apparently shared with binutils but not yet mentioned. The others are not yet mentioned (and shared between gdb and non-binutils libraries).
• Do we want to break it up into separate entries (libibery and gnulib have separate entries, maybe we want bundled(libbfd), bundled(libopcodes), etc as well)

Okay, spot and tibbs were available to talk after the meeting. It seemed that ticket 43 fell under this exception so I've rewritten the page some more. If anyone objects, feel free to ping me/mention in this ticket and I'll revert the change until we can vote at the next meeting.

binutils libraries (libbfd, libcpu, libopcodes, libdecnumber)

bundled(binutils)

If the package in question shares the same upstream as binutils (sourceware.org), they may bundle these libraries. This is because the libraries are developed by the application authors as common functionality shared between several applications. Being developers of both, they'll be intimately aware of both issues that arise in the libraries and know how to port to newer versions of the library as needed. Note that, at the moment, all of these applications and libraries come from sourceware.org but not all of them are used in binutils. The name was chosen as it seemed to be the more permanent and recognizable name.

Notes:
* I'm closing the gdb ticket with the note that their request has been granted under the provisions of this ticket.
* I did not merge gnulib and libiberty into here. There's two reasons
1. It's a change to the Provide: so we'd want to audit the package set and update those
2. It's a limitation of what was approved for those libraries (ie: only from sourceware instead of may be bundled by anything).

We can discuss any of that at the next meeting if desired.

Therefore there should be:
{{{
Provides: bundled(libiberty) = XXX
}}}

But which version to put in XXX? '''libiberty''' is distributed only as a part of the applications ('''binutils''', '''gdb''', '''gcc''' etc.) where each app has its own versioning scheme.

Unrelated question #2:
libiberty contains md5.c by Ulrich Drepper. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#cite_note-1 does not list it. Should there be:
{{{
Provides: bundled(md5-Drepper) = XXX
}}}
or is it already covered by that:
{{{
Provides: bundled(libiberty) = XXX
}}}

The impression I've received when we passed this is that libiberty has its own SCM repo but that that repo is forked into each application when the application is getting ready to release. With that in mind, some versioning scheme that 1) shows sequence and 2) relates to the version control system seems appropriate. It might be best to use the date that the checkout was made similar to the Fedora Package Naming Guidelines for snapshot versions.

For #2, please file a new ticket where we can look at the code and assign an appropriate name for the bundled() virtual provide. Also note that what the virtual provide captures is not the existence of an md5.c filename in a tarball but the existence of an md5 implementation that was not written solely for that software. If Ulrich Drepper wrote this md5.c file and it is being used or simply distributed separately from libiberty as well as with libiberty, then we want to create the virtual Provide to mark it. If Ulrich Drepper wrote this md5.c for use in libiberty and it's not distributed or used separately, then there isn't a need to mark it.

Replying to [comment:9 toshio]:

It might be best to use the date that the checkout was made similar to the Fedora Package Naming Guidelines for snapshot versions.

Used:
{{{
%global snap 20120103
Provides: bundled(libiberty) = %{snap}snap
Provides: bundled(gnulib) = %{snap}snap
Provides: bundled(binutils) = %{snap}snap
}}}

For #2, please file a new ticket where we can look at the code and assign an appropriate name for the bundled() virtual provide.

Filed: [https://fedorahosted.org/fpc/ticket/130 Ticket 130]

Looks good! You can leave off the literal "snap" in the version if you like (the date, %{snap}, alone would be sufficient).

We discussed this at the meeting today. We think that the literal "snap" should be left off but otherwise it's great. So the example becomes:

{{{
%global snap 20120103
Provides: bundled(libiberty) = %{snap}
Provides: bundled(gnulib) = %{snap}
Provides: bundled(binutils) = %{snap}
}}}

It is already this way now in {{{gdb-7.4.50.20120103-7.fc17}}}. It requires extra maintenance of the timestamp during rebases so I have not modified nickc's binutils myself.

Announce Text:

An exception was granted which permits the bundling of binutils libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber) but only to packages which share the same upstream as binutils (sourceware.org). This is because the libraries are developed by the application authors as common functionality shared between several applications. Being developers of both, they'll be intimately aware of both issues that arise in the libraries and know how to port to newer versions of the library as needed. Note that, at the moment, all of these applications and libraries come from sourceware.org but not all of them are used in binutils.

Packages leveraging this exception must add: Provides: bundled(binutils) = %{snap}, where %{snap} is defined in the package as the date that the binutils checkout was made, until the bundling issue is resolved (if ever).

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions