Bug#860055: Inquiry about packaging progress

[Stefan Bühler <stbuehler@web.de>]

Hi again,

On 08/31/2017 12:17 AM, Christoph Biedl wrote:
> Christoph Biedl wrote...
> 
>> * The build failure on i386 (also seen on armhf) and probably
>>   all other 32bit archs needs to be fixed.
> [...]
This is fixed upstream now:
  https://github.com/dino/dino/commit/dc26841b9e

I updated my package for this new snapshot, and it seems to build
(32-bit too) and run (tested 64-bit) ok.

There is also this:
https://build.opensuse.org/package/show/network:messaging:xmpp:dino/dino
(https://download.opensuse.org/repositories/network:/messaging:/xmpp:/dino/Debian_9.0/)

Upstream seems to be involved with this package, but:
- They reuse the "dino" name (which is still used in oldstable - can it
  be reused already? should it be reused?)
- There is a dev package, but no lib package; that is probably a bad
  idea
- A dev package requires IMHO a commitment to stable ABI (and SONAME
  bumps), and given that there isn't even a release yet I wouldn't rely
  on that.
- The platform independent files are not in a separate package.
- The magic "_service"-link to automatically update on each commit seems
  to package git-submodules directly (so they don't need the symlink
  hack I had to use in debian/rules)

Imho unresolved:

a) libsignal-protocol-c should be packaged separately (#840366)
b) I didn't check the source for any other inlined (re)sources which
   might already be packaged separately, and I didn't check the licenses
   either.  Did someone else check?
c) There are 3 shared libraries provided by the package, which the
   plugins link against, so they can't be linked statically.  But they
   are in the standard shared library directory.

   I don't think upstream is ready to provide a stable API yet, so a
   separate dev and lib package imho doesn't make sense (otherwise you'd
   have to so-bump on every release).

   What is the correct way to package these shared libraries in the
   meantime?  Append the package version to the binary basename?

   One day dev and lib package could be provided, is it possible to
   split the package then without so-bump with the current names?

   I went with renaming the "qlite" and "xmpp-vala" shared libraries to
   "dino-qlite" and "dino-xmpp-vala" for now, so they at least live in
   their own namespace (and this might be a good idea even in the long
   run - maybe ask upstream to do the same?).
d) lintian:
   W: dino-xmpp-client: desktop-mime-but-no-exec-code usr/share/applications/dino.desktop
e) "dino" vs "dino-xmpp-client"?

cheers,
Stefan