Package: entangle
Version: 3.0-5
There seems to be some confusion about the status of Entangle-0.1.typelib
and entangle's frontend and backend shared libraries, and this has led
to a circular dependency between the entangle and gir1.2-entangle-0.1
packages.
There are two possibilities for how the upstream developer intended this
app to work:
1. It has libraries that are available for others to link against, like
for example evince and rhythmbox do.
If this is true, then the libraries should be packaged like "proper"
libraries, with a -dev package containing public headers and the .so
symlink, one or more runtime library packages containing the .so.0
symlink and the actual library, and so on. For more details, see
Policy ยง8 for the C library side, and the GObject-Introspection
mini-policy
<https://salsa.debian.org/gnome-team/gobject-introspection/-/blob/HEAD/debian/policy.txt>
for the GObject-Introspection side.
But, if this is true, then it needs to have a stable API/ABI, just
like evince or rhythmbox; and for its API to be useful, it would
likely need to install header files.
If it's this, then I would expect a dependency structure more like:
entangle -> gir1.2-entangle-0.1 -> libentangle-frontend0
which would resolve the circular dependency.
Or,
2. Its libraries are private, and not intended to be accessible to code
outside the entangle source package, similar to gnome-characters.
If this is true, then the libraries and typelib should be installed
into a private directory, conventionally get_option('libdir') / 'entangle'
("pkglibdir" in GNU terminology); the main entangle executable should
be linked with a suitable DT_RUNPATH to find them (Meson should do
this automatically); and the GObject-Introspection setup will need to
call g_irepository_prepend_search_path() and maybe
g_irepository_prepend_library_path()
(or gi_repository_prepend_search_path() and
gi_repository_prepend_library_path() after fixing #1118501) to ensure
that the typelib can be found.
If it's this, then the wrong solution for #695342 was chosen,
and the solution should instead have been to move the typelib to a
private directory; and there would be no need to separate entangle
from gir1.2-entangle-0.1.
If this is the correct interpretation, then there is no need to
install header files (/usr/include) or the GIR XML (.gir file).
Which one is it?
These are two mutually exclusive options, and without the benefit of the
package maintainers' better knowledge of this package, I can't know
which one is right. But surely one of them must be correct, and having a
mixture of the two certainly seems like it is having undesirable
consequences.
smcv
