Bug#1118608: entangle: Seems confused about whether its API is public or private

[Simon McVittie]

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