packaging-committee

Clone
Source Code
GIT

#1049 no existing guidelines for packaging GObject typelib / gir / vapi files
Opened 3 years ago by decathorpe. Modified 3 years ago

Open
Close issue as:
accepted rejected nothingtodo invalid fixed wontfix duplicate temporaryexception permanentexception exceptionexpired

GObject based C libraries often provide bindings for other languages based on GObject Introspection / GIR. Some packages ship those introspection files with the main library. Some split them off OpenSUSE-style into typelib-foo-1.0 subpackages. Some projects also provide language-specific enhancements overrides to those introspection-based bindings.

There are no Guidelines for how to split those things into multiple subpackages, if at all:

  • main library
  • typelib / GIR / VAPI files
  • language specific overrides (e.g. for python3)

This package may be a good example: signon-glib

  • .typelib file in main package (with library)
  • .gir / .vapi files in -devel subpackage (with pkgconfig and header files)
  • python overrides in python3-signon package

BTW, I'm not saying that this is the correct way to do things. But it's the best solution I came up with at the time.

I initially split off python3 overrides into a separate package (python3-signon) because using those also pulls in python3-gobject unconditionally, which might not be desirable when using the plain C library. Other packages I have looked at ship it with the main library, sometímes adding the Requires on python3-gobject, sometimes not.

I suggest the following new guidelines:

  • .typelib files are loaded at runtime, so they should be in the same subpackage as the library they provide introspection-based bindings for
  • .gir and .vapi / .deps files are read at build time, so they should be in the same -devel (?) subpackage as the unversioned .so, headers, and pkgconfig files of the library it provides bindings for

Where language-specific overrides / enhancements for those introspection-based bindings should go I am not sure. For python3, a separate subpackage with the appropriate Requires: python3-gobject and Requires: main-library = %{version}-%{release} seems like a good idea, but including it with the main library subpackage should be fine too.

Thoughts?

Why do we still lack dependency generators for this? Both Mageia and openSUSE generate typelib() dependencies so that dependencies are correctly matched.

The main reason for wanting to subpackage out the typelib files is to avoid requiring gobject-introspection as a runtime dependency for the main library packages when they're unneeded (since the g-i repository paths are in that package).

+1 from me. This is exactly how we've been doing this in GNOME packaging in Fedora and codifies the status quo.

Should the guidelines also mention how to package the directories? In the signon-glib example above it leaves behind unowned:

%{_libdir}/girepository-1.0
%{_datadir}/gir-1.0
%{_datadir}/vala
%{_datadir}/vala/vapi

directories. These should also be owned by the package that installs files in there (or alternatively we could make filesystem own them).

Why wouldn't we have -filesystem packages for those?

Should the guidelines also mention how to package the directories? In the signon-glib example above it leaves behind unowned:

%{_libdir}/girepository-1.0
%{_datadir}/gir-1.0
%{_datadir}/vala
%{_datadir}/vala/vapi

directories. These should also be owned by the package that installs files in there (or alternatively we could make filesystem own them).

You are right. I thought they were owned by glib2-devel or gobject-introspection-devel, because that would make the most sense, instead of all packages owning them.

Where language-specific overrides / enhancements for those introspection-based bindings should go I am not sure. For python3, a separate subpackage with the appropriate Requires: python3-gobject and Requires: main-library = %{version}-%{release} seems like a good idea, but including it with the main library subpackage should be fine too.

I think I'd prefer it if we kept the convention of having the python3-library as a separate subpackage, irrespective of whether it contains overrides. Here's my reasoning:

  1. If we want to add overrides later, we don't need to inflate the library size or deal with the headaches of splitting the package at that time.
  2. Consistency is always good: most python packages would expect to do Requires: python3-foo for most of their other dependencies. Further, it makes it easier down the line to swap it out with a different implementation, should the need arise.
  3. It allows packages maintainers to make clear what languages the package formally supports. Just because GObject Introspection provides bindings for an arbitrary language doesn't mean that it will work cleanly (for example, there are portions of libmodulemd that are painfully difficult to use from Python without the overrides to handle type conversions). It doesn't prevent others from using those bindings, but it DOES help indicate to them that they may not work for all cases (and may also lead to Fedora packagers communicating with upstream to add proper support).

Login to comment on this ticket.

Metadata
None
None
None
None
Needs Review
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.