Source: srpc
Source-Version: 0.9.6-1
Severity: normal

Hi!

This package has a rather unorthodox package contents organization. There
are two binary packages generated:

  a) libsrpc-dev: Contains the usual headers (but no .a archive
     nor .so symlink or linker script).
  b) libsrpc: Is an unversioned package (given that there's no actual
     shared library), that contains the .a, .so and versioned .so
     symlink, in addition to an IDL generator program.

This is rather non-standard, and problematic for multi-arch, and is
not future-proof, in case upstream starts providing/supporting a
shared library.

Ideally the .a archive and the .so linked script (which just redirects
the linker to always use the .a archive, so there's no actual shared
library), should be moved into the libsrpc-dev package as the usual
convention. The versioned .so symlink (libsrpc.so.0.9.5) should be
removed, as there should be no object dynamically linked against that
(given that it points back to the .so linker script which does not
resolve at run-time) to avoid confusion.

Then the srpc_generator program would be moved into a new libsrcp-bin
binary package to make this separation more clear. And the libsrpc
binary package can then be dropped. (All with the required
Replaces/Breaks relationships.)

At that point the libsrpc-dev can be marked as Multi-Arch: same, and
the libsrpc-bin (assuming the generated contents are arch-independent)
can be marked Multi-Arch: foreign.

If there's ever an actual shared library, then it would be packaged as
say libsrpcN (with N being the SOVERSION), containing the .so.N.O
shared library.

Thanks,
Guillem

Reply via email to