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

Hi Guillem,

Thank you for checking in to this.

Please help me understand. When I packaged 'workflow' for the upstream
authors, I created libworkflow1 and libworkflow-dev. libworkflow1 provides
the libraries/objects while the -dev package depends on libworkflow1 and
includes the header files. I thought this was the convention?

OK. This is doable. I was unsure how to structure the package to include
this binary.

I based my packaging of SPRC based on workflow and both passed the mentors
list. If there is a better or more standard away of doing things, I am
happy to adjust.

Is there a system in Debian that flags this "unorthodox" organization for
review? I'm curious how you came across this since workflow was done in a
very similar fashion but no one commented. I am always learning and want
to make sure I fix errors made in the past and avoid them in the future.

Do you have a reference package I could look at? It would be helpful
to base my work off of something that meets the standard.

Thank you,

Lance Lin <lqi254@protonmail.com>
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

Not really no. The workflow packages look like needing further fixing
too, I'll file a report for that one separately. :)

The .a and .so pathnames are shipped in the -dev package because they
are only useful during development, and because they contain unversioned
pathnames that would otherwise conflict with their counterparts from
other supposedly co-installable shared library packages.

The point of versioning the shared library packages is precisely so
that they can be co-installed, which makes (distro) transitions and
system upgrades way smoother. Say bin-pkg-a links against libsome1
from the libsome source package, then libsome gets updated and bumps
its shared library package to libsome2 which bin-pkg-b links against.
This means a user can happily have bin-pkg-a → libsome1 and
bin-pkg-b → libsome2 installed at the same time while the others get
rebuilt, this also means packages can be rebuilt against a later version
libsome-dev → libsome2 even if they transitively Build-Depends on
something that depends on libsome1, otherwise that build-dependency
chain could not be installed.

This is covered in debian-policy §8.

See above.

It seems lintian does not have any check for something like this, it
does notice other things, such as the Section for libsrpc-dev being
wrong and the Architecture, but nothing more. I guess the problem is
the combination of unversioned shared library package, with no actual
shared library and instead a linker script, which all are rather
unusual.

This specific case I noticed as I tend to check any unversioned shared
library package that appears as a new package on aptitude. Otherwise
I'd probably have not noticed, like the workflow one.

Also I guess not all reviews are made equal. :)

The libbsd source package also ships a linker script as its .so
pathname, even though that one contains an actual shared library
with a versioned SONAME.

For a more usual package, perhaps libmd would do.

Thanks,
Guillem

We believe that the bug you reported is fixed in the latest version of
srpc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1012004@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Lance Lin <lqi254@protonmail.com> (supplier of updated srpc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 16 Jun 2022 19:39:19 +0700
Source: srpc
Binary: libsrpc-bin libsrpc-bin-dbgsym libsrpc-dev libsrpc0 libsrpc0-dbgsym
Architecture: source amd64
Version: 0.9.7-1
Distribution: unstable
Urgency: low
Maintainer: Lance Lin <lqi254@protonmail.com>
Changed-By: Lance Lin <lqi254@protonmail.com>
Description:
 libsrpc-bin - Sogou RPC Library (SRPC) Generator
 libsrpc-dev - Sogou RPC Library (SRPC)
 libsrpc0   - Sogou RPC Library (SRPC) Generator
Closes: 1012004
Changes:
 srpc (0.9.7-1) unstable; urgency=low
 .
   * Updated to new version (0.9.7)
   * Restructured package based on feedback. Closes: #1012004
   * Added support for dynamic library (new in 0.9.7) via libsprc0
   * d/control: added breaks/replaces for piuparts
Checksums-Sha1:
 ed2c22916d6488a8f1b5df6a8419dd31aec7d354 1858 srpc_0.9.7-1.dsc
 633ce58e937cba7f363d63451741fb121cb79d1f 356577 srpc_0.9.7.orig.tar.gz
 228eedc816a4ec9317be8404e3a5c4597da5dfe8 3276 srpc_0.9.7-1.debian.tar.xz
 d93777ecf5e4be63ca445366c4ad11f4edd27f5a 870572 libsrpc-bin-dbgsym_0.9.7-1_amd64.deb
 c1b23d98085a80c3762225da0b7ee75ea40e0f22 56308 libsrpc-bin_0.9.7-1_amd64.deb
 8254c1a87c6db95c8515a7dde51ea78195e28111 300324 libsrpc-dev_0.9.7-1_amd64.deb
 b876af66e7eda86c57b16b996771eb9601322ac9 3603276 libsrpc0-dbgsym_0.9.7-1_amd64.deb
 d212931a841d74ac9704945991cd38a4ab1a5e35 365912 libsrpc0_0.9.7-1_amd64.deb
 e2e691cf3b86406b280f8e9a5ec59931b6c258a5 7797 srpc_0.9.7-1_amd64.buildinfo
Checksums-Sha256:
 6da679875624f2610e632d4f30ad287cf19616add7472f4bf570bd5366821584 1858 srpc_0.9.7-1.dsc
 40053bfacce7cbc843aa3892bb0f317860336713b59ae0e2c797eee419323da5 356577 srpc_0.9.7.orig.tar.gz
 3bab15547a9379b798a98f52608201c3a535e9500dac9f657a51ceaef84206ed 3276 srpc_0.9.7-1.debian.tar.xz
 e42058c4625eaf2316899f8a34225d403722a8c8913bff4bb2ea41a8d02b612a 870572 libsrpc-bin-dbgsym_0.9.7-1_amd64.deb
 7b006f273e44b02b585cf0437d6f9d6c4e69b67dcf68b373185093f3531f15a8 56308 libsrpc-bin_0.9.7-1_amd64.deb
 7c274c55a326e3703ebfeea4a9724b2103ce8327b2a61ba447eab9b313e793ba 300324 libsrpc-dev_0.9.7-1_amd64.deb
 0e3427965767040e44bc816edf0109dd57c7c5921ce7521c8b791d3393718635 3603276 libsrpc0-dbgsym_0.9.7-1_amd64.deb
 8d20595aad0fbadddabb1f8232263549c37cbd7499d02949e50d88f0c1a32d1b 365912 libsrpc0_0.9.7-1_amd64.deb
 86987559037c1d0e11151518952a10342b939e33ad7eacab6ddff584ed711522 7797 srpc_0.9.7-1_amd64.buildinfo
Files:
 69c99a68ad74385df3477bb6582b9ea1 1858 libs optional srpc_0.9.7-1.dsc
 e1d42003f1142f4677e8f14e888a18cf 356577 libs optional srpc_0.9.7.orig.tar.gz
 0c5f303225e402efa22a0a24d1d1792e 3276 libs optional srpc_0.9.7-1.debian.tar.xz
 b4b4df4a5e0628dc3f3d59b9ba1cf479 870572 debug optional libsrpc-bin-dbgsym_0.9.7-1_amd64.deb
 d6081a881dd529d75c9cd1c68e8112f6 56308 libs optional libsrpc-bin_0.9.7-1_amd64.deb
 bbeefff6f02b115ce1cb67dc1787f043 300324 libs optional libsrpc-dev_0.9.7-1_amd64.deb
 3712f896af1e4d64e8122bf5b0c648a2 3603276 debug optional libsrpc0-dbgsym_0.9.7-1_amd64.deb
 3a9d23025fdc66bddce1337e1741846d 365912 libs optional libsrpc0_0.9.7-1_amd64.deb
 701c892c5500097a2098b8476d11b515 7797 libs optional srpc_0.9.7-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEQGIgyLhVKAI3jM5BH1x6i0VWQxQFAmK4ipkQHGJhZ2VAZGVi
aWFuLm9yZwAKCRAfXHqLRVZDFL69C/9Mov/a2JMSdeW/JmJF996YJPa667i+edbm
QP/Z1yBfh65N1Db6+30J9lbTeNVaNr6pE7tN+ApV2l1ab1Fuuax6Eq5hv+gIQRny
pj4VvLyxCi8kptyInA5BEofVP+zZSkuTsUUcZWLmrsq7rpetrVYhdbtFt1kfBxdk
c6maMsnzgNR3D8tHwWSNsHe5U4JxiTpw3MXsV/1LcZP1luEJucvxOFWMri4biw3q
91BMpkqir8XBdRxqysWvPci8xoaJNLcPXc9VkZDTQ74fyJWMFfziZQGGH8F9ykpD
b39FjUNfWxq/oRYawNK5GFV5PKhlMjThuKYjKRQMp2jNJnG7icfw4xfQ7S/aAYPs
y7o9BB5+paTyckEJf2J1X6KEw3T22qkZLR2ZEU9sv1K8qLVpt0XciR1bj6u+qMYc
oatZud0mSz6ZvW2yNCuUF8UqtkgJOk4yPc1DX6VYPPR2/NFgSJunLDxLuOe5O++s
mxTOc5NWL1uDtqZTDTFn3rvQ+KEIXl8=
=1SKZ
-----END PGP SIGNATURE-----