Ticket #109 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Request to allow the binutils libraries (bfd, opcodes) to be bundled

Reported by: nickc Owned by: spot
Priority: minor Milestone:
Component: Bundled Library Exception Version:
Keywords: binutils Cc: jankratochvil
Blocked By: Blocking:

Description

Hi Guys,

Currently the Binutils package installs two libraries - libbfd and libopcodes. The binutils-devel subpackage installs shared versions of these libraries, but as BZ 702648 shows, it does not also install all of the header files and configure scripts to make use of these shared libraries.

I would like to ask that the binutils libraries to be considered as bundled libraries and remove them from the binutils' package installation altogether. The reason for this is that the API for these libraries is unstable, and in fact has been known to change between different releases of the same version. I believe that this will only affect a few other packages, (gdb, insight, maybe a few more) and that it will not have a large effect on Fedora overall.

Alternatively, if the consensus is that the libraries should be included with the binutils package, then please may I have some guidance as to where the additional files (headers, autoconf files and cgen input files) should be stored ?

Cheers

Nick Clifton Binutils Maintainer

Change History

comment:1 Changed 3 years ago by spot

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

comment:2 Changed 3 years ago by toshio

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.

comment:3 Changed 3 years ago by toshio

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

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.

comment:4 Changed 2 years ago by nickc

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

comment:5 Changed 2 years ago by spot

  • Owner set to spot
  • Status changed from new to assigned

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

comment:6 Changed 2 years ago by toshio

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)

comment:7 Changed 2 years ago by toshio

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.

comment:8 Changed 2 years ago by jankratochvil

  • Cc jankratochvil added

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

comment:9 follow-up: ↓ 10 Changed 2 years ago by toshio

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.

comment:10 in reply to: ↑ 9 Changed 2 years ago by jankratochvil

Replying to 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: Ticket 130

comment:11 Changed 2 years ago by toshio

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

comment:12 Changed 2 years ago by toshio

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}

comment:13 Changed 2 years ago by jankratochvil

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.

comment:14 Changed 2 years ago by spot

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

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

Note: See TracTickets for help on using tickets.