#383 Bundled library exception request for libgsystem
Closed: Invalid None Opened 8 years ago by puiterwijk.

I would like to request a bundled library exception for libgsystem (https://github.com/GNOME/libgsystem), which is a copylib as per https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs.

It is already used by a lot of other projects as such (NetworkManager and lots of GNOME stuff for example).

Correct URL for libgssh is https://git.gnome.org/browse/libgsystem/ (thanks to Colin Walters for correcting me).

Yet another "copylib"! When will this madness stop? Do we really want to allow any and all bundled code just because upstream tagged it with the magic "copylib" word? I don't see why this (and several other "copylibs") cannot be built as a proper library!

Please see the FPC bundling request process and provide all the information. As Kevin said, just because upstream uses the magic copylib keyword doesn't mean we'll let everyone bundle it in 666 packages in Fedora.

In addition to the standard information ( https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions ), having a list of the packages bundling this library would be helpful to let us know if this is mostly gnome software with a few outliers or happening in all sorts of disparate software.

libgsystem is just used by a few modules I maintain (ostree, hotssh, gnome-continuous, rpm-ostree), the latter 2 of which aren't packaged (yet). Plus cockpit, NetworkManager, plus gnome-terminal. That I know of anyways.

It really has three parts:

  • libgsystem-local-alloc: Literally 150 lines of inline functions (i.e. no .so) for making
    memory management easier (can't go in GLib since it won't work on Windows/MSVC)
    Most of the consumers only care about this, and I may split it out.
  • GLib backports (so we can build new NM on older versions of EL)
  • Some Unix-only system API that I might eventually fold back into GLib, but need
    serious thought.

None of these are particularly security sensitive.

In the next year or so, I suspect the second two parts will drain slowly into GLib.

Soo...personally I think it's not a big deal if it remains a git submodule (it's easy
to update), but there is definitely an argument to be made for it to be a shared
library, and if that's the consensus here, I can see about doing it.

/me Making sure this gets noticed for discussion at meeting

The information in comment:5 sound like they may be a reason to track this as a static library. What's the rationale for bundling as opposed to static?

Sorry, I forgot I still had this open.

This is no longer an issue as libgsystem has been released as a proper shared object, and as such no longer requires a bundling exception.

Metadata Update from @walters:
- Issue assigned to toshio

4 years ago

Login to comment on this ticket.