Bug#1039714: gobject-introspection: dh_girepository does not fetch all symbols from GIR files

[Thomas Uhle]

Hello Simon,

thanks a lot for this nice description!

I am also not an author of dh_girepository but happen to understand Perl 
code.  So I had to work out how it works just from the code.  I am sorry 
that I was a bit short in my previous e-mail.  I could have delivered some 
more explaining thoughts.  As far as I understand, it was easier for the 
author(s) of dh_girepository to utilize dpkg-shlibdeps to determine the 
dependencies on shared libraries.  That is why dh_girepository simply 
dumps every found symbol in a dummy C file that is then compiled and 
linked to a shared library itself (for each GIR file a seperate shared 
library).  dpkg-shlibdeps uses these temporarily built shared libraries 
to determine the dependencies.  So dh_girepository does not need to look 
up each and every symbol in /var/lib/dpkg/info/*.symbols itself to 
generate ${gir:Depends} into debian/gir1.2-*.substvars.

You are right, the code responsible for parsing the GIR file was just 
recognizing symbols that resemble ordinary functions, methods and 
constructors and ignoring other symbols.  In the case of HarfBuzz-0.0.gir 
this has led to the situation that the *_get_type() function from 
libharfbuzz-gobject.so.0 were ignored and, thus, not in the dummy C file. 
Because these functions has yet been the only functions in 
libharfbuzz-gobject.so.0, dpkg-shlibdeps could not determine the 
dependency to this shared library and so libharfbuzz-gobject0 has been 
missing in ${gir:Depends} and finally in the control file of 
gir1.2-harfbuzz-0.0.

That is why I have studied gir-1.2.rnc (part of libgirepository1.0-dev) 
to find out which XML elements are used for native symbols.  Apart from 
(virtual) methods, constructors and ordinary functions, these symbols can 
also be part of the definitions of types such as classes, interfaces, 
enumeration types, records, unions, etc.  While adding support for virtual 
methods was quite easy by simply tweaking the already existing regular 
expression, I had to make up a new regular expression for parsing the XML 
attributes of the type definitions.  Next to *_get_type(), there can also 
be functions for the reference counting of objects, getters and setters. 
That is why this new regular expression is a little more complex than the 
one that was already there.


On Wed, 28 Jun 2023, Simon McVittie wrote:

> Thanks for the patch, please could you add a bit more context for what
> it's doing and why it's necessary/correct?
>
> I didn't write dh_girepository, so I'm having to work this out from first
> principles, but as far as I understand your patch, the explanation would
> go something like this:
>
> ---
> dh_girepository: Discover more symbols in GIR files
>
> dh_girepository creates and compiles a dummy C library that aims to
> refer to all the same symbols that are mentioned in the GIR XML, so that
> running dpkg-shlibdeps against that library will generate the union of
> all the dependencies that would be necessary to provide all the symbols
> that a GObject-Introspection binding could get from the typelib. It does
> that by parsing the GIR XML and looking for XML elements that refer to
> a C symbol.
>
> It was already able to recognise *some* XML elements that refer to a C
> symbol: ordinary methods, constructors, and ordinary functions. But it
> didn't recognise virtual methods, the get_type() functions of various
> GObject types, or other functions that are conceptually part of a
> type such as copy and free functions. The result was that if a library
> *only* contains virtual methods and get_type() functions - for example
> libharfbuzz-gobject, which exists solely to provide get_type() functions
> for objects in libharfbuzz - then no dependency on that library would
> be generated, leading to ${gir:Depends} being incomplete.
>
> Closes: #1039714
> ---
>
> Is that accurate? Or if not that, then what?

That is perfect.  Thanks a lot!

Best regards,

Thomas