After an insightful discussion with Sebastian, and taking into account
other suggestions from the list, here is a new proposal.
1. Directory layout
GObject-introspection data is generally provided in two formats:
* XML format in /usr/share/gir-1.0/Foo-X.Y.gir
* binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
2. Binary introspection packages
The binary typelib file must be put in an architecture-dependent package
named after its namespace. The name should be gir1.0-NAMESPACE-VERSION.
For example, the package containing WebKit-1.0.typelib will be named
gir1.0-webkit-1.0.
Giant repositories of unrelated introspection data should be avoided.
(Under this rationale, gobject-introspection-repository will be split.)
However, related libraries that are known to evolve together can live in
the same package (example: Gst*-0.10).
Introspection packages belong in section libs for the moment. If there
are enough packages to justify it, a new section will be requested to
the FTP masters.
3. XML introspection data
The XML format introspection must be shipped in another
architecture-dependent* package of the same source.
* This is so that it is guaranteed to be accessible at
build time by the tool that will compute the
dependencies for the .typelib files.
If the source package also contains the library itself, this data should
be in the development binary package. If the introspection data is split
from the library source (e.g. for gobject-instrospection-repository), a
separate package containing this XML data can be created, in section
libdevel.
The package containing the XML data doesn’t need to depend on the
introspection package. It can contain XML data for several unrelated
libraries, since in the end it doesn’t depend on them.
4. Dependencies of introspection packages
Introspection packages must depend on the libraries they reference, with
a sufficient version for the symbols they reference.
For that effect, I propose to introduce a new helper, dh_girepository,
in the gobject-introspection package (which is already a
build-dependency for introspection packages). It would wrap
dpkg-shlibdeps so that the dependencies are the same as those of similar
ELF binaries.
Introspection packages must depend on other introspection packages that
are referenced through <include> statements. The helper should generate
such dependencies as well.
Packages containing the XML data don’t need any specific new
dependencies.
5. Dependencies on introspection packages
Currently, there are only Seed (JavaScript) scripts to use these
introspection packages. In the future, there might also be Python or
other interpreted languages.
Generating dependencies automatically for interpreted languages is not
reliable. Therefore, these packages must depend by hand on the
appropriate gir1.0-* packages. The interpreters themselves don’t need to
depend on packages they don’t use directly.
6. Example
Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
source generates the following files, put in the following packages:
libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib
libfoo-2.0-dev Depends: libfoo-2.0-3, libbar-3.0-dev
gir1.0-foo-2.0 Depends: ${gir:Depends} which expands to:
libfoo-2.0-3, gir1.0-bar-3.0
If foobar is a package containing the following JS script:
#! /usr/bin/seed
Foo = imports.gi.Foo;
// Stuff that uses the Foo 2.0 API
Then foobar Depends: gir1.0-foo-2.0
I’ve started preliminary work on dh_girepository. The first version will
be a bit hackish and will rely on building an intermediate binary
referencing the appropriate symbols that will be fed to dpkg-shlibdeps.
Doing better will require extending dpkg-shlibdeps so that it accepts
another input format than ELF (it doesn’t have to be the GObject XML
format, it could be anything easy to generate).
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=