Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[wferi@niif.hu]

Seunghun Han <kkamagui@gmail.com> writes:

>>>   swtpm - Libtpms-based TPM emulator
>>>   swtpm-dev - Include files for the TPM emulator's CUSE interface
>>>   swtpm-libs - Common libraries for TPM emulators
>>
>> Why do you deviate from the usual libswtpm-dev/libswtpm0 package names?
>> Including the SO version in the package name enables installing
>> incompatible versions side-by-side, which is useful.
>>
>> Also, shipping static libraries (like libswtpm_libtpms.a) is generally
>> recommended against in Debian.  Does this package warrant it?
>
> The upstream version already has some debian-related files, and I
> changed them to adopt the package. The author of it wants to name it
> like libswtpm0, so I used the name. The static libraries are also
> involved in upstream debian files. Should I change the name like
> libswtpm instead of libswtpm0 and remove static libraries from the
> package?

I questioned the package name, not the names of the shared object
within.  After a closer look, though, libswtpm_libtpms.so.0.0.0 looks
more like an internal convenience library than something which other
projects call into.  If this is so, the package name loses its
relevance, I wonder why it's packaged separately, even.  Or why it isn't
compiled straight into the single binary (swtpm) linked against it.

>>>   swtpm-tools - Tools for the TPM emulator
>>
>> Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and
>> swtpm-localca into /usr/share/swtpm instead of /usr/bin?  (This emits
>> several Lintian information tags.)
>
> The author of the upstream project wanted to put them to
> /usr/share/swtpm. The files are just for the initialization and don't
> be used for TPM operations directly, so maybe he wanted to put
> /usr/share/swtpm instead of /usr/bin. Should I move them to /usr/bin?

That they have man pages suggests that they are meant for human use.
That their man pages are in section 8 suggests that they should live in
/usr/sbin.  But this is unreliable, since even the *.conf man pages are
in section 8, while those belong to section 5.  This actually depends on
whether the executables are generally used by the system administrator
or nonprivileged users (or only internally, in which case the scripts
would indeed belong into /usr/share/swtpm).  I started to suspect that
the current decision wasn't based on the expected usage pattern, but
rather on the implementation method (interpreted script or compiled
binary), which isn't very useful.  But I know too little about the swtpm
ecosystem to be sure about the best filesystem layout for the future.
-- 
Regards,
Feri