1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
Library packages
================
The upstream fastrpc library comprises six shared libraries and one set
of include files. The shared libraries are in pairs, supporting three
classes of DSP. The shared libraries for each class support a common ABI
that corresponds to the single API provided by the include files. The
underlying implementation across the classes is actually the same.
The common API and ABI support two separate methods: old and new. In the
old method, the DSP to use is chosen by which of the three library
classes you linked against at build time. In the new method, the caller
specifies the DSP to use in the API call, and the underlying
implementation is the same. It does not matter which shared library was
linked against, but different builds already released by third parties
may have used different ones.
Therefore, and after discussion with upstream, it seems likely that if
there is an ABI change, all sonames will change at once. There are no
current plans to do this, but if it happens it is likely to be
libfastrpc.so.2, bringing together the previous split. For this reason,
bundling the different shared libraries into a single Debian package is
safe, as permitted under Debian policy section 8.1.
libfastrpc1 ships all six shared libraries, and libfastrpc-dev ships the
six .so symlinks and the single set of headers.
Test suite binaries
===================
Currently upstream is unable to ship the sources for the test suite that is
included in the upstream release for technical toolchain reasons, contrary to
DFSG. Upstream aim to address this and this is tracked upstream at
https://github.com/qualcomm/fastrpc/issues/235.
However, they remain licensed under BSD-3-Clause, so are redistributable
by Debian. For this reason, I didn't bother with a repack to exclude the
files, instead just ensuring that these do not end up in any binary
builds. The upstream build system simply installs these directly with
`make install`, so it is trivial to put these files into
debian/not-installed with a high degree of confidence that they will not
slip through.
lintian source-contains-prebuilt-binary tags are overriden accordingly,
but only for the current set of named files so as not to miss anything
else that might have a different reason for being present.
Since the build system selects 'linux' and not 'android', binaries
shipped in test/android/ do not get installed by `make install` and
therefore do not appear in debian/not-installed even though they are
overridden in lintian.
|
