Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
On Sat, Apr 28, 2018 at 01:58:26PM +0300, Dmitry Eremin-Solenikov wrote:
> > 5. Could you explain why these lines exist? Package libodp-linux-dev
> > seems not exist.
>
> Packages libodp-linux-dev and libodp-linux119 are virtual package,
> provided by different implementations of ODP API. We are providing
> another ODP implementation, implemented specifically on top of DPDK
> (https://github.com/Linaro/odp-dpdk). It is not packaged (yet). These
> two implementations are binary compatible. It is planned that odp-dpdk
> will have libodp-dpdk119 (Provides: libodp-linux119) and libodp-dpdk-dev
> (Provides: libodp-linux-dev) packages.
>
> Would you recommend how should I better document and/or implement these
> packages.
How many libodp-linux.so.119 providers are there?
If there are only a few alternatives, why should we make a virtual
package, whose SOVERSION might bump regularly? From the policy we can
find a list of authoritative virtual packages:
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
All of these packages are widely used and be depended by a lot of
packages. If the list of libodp-linux.so.* providers is short, we can
write the Depends field of an application package like this:
Depends: libodp-implement1 | libodp-impl2 | ...,
where there is no virtual package.
According to your current debian/control, it seems that there can be
only one libodp-linux119 provider existing on system at the same time.
I'd really suggest to fix it before uploading, because you planed to
upload another implementation.
I think you have just written a better solution in the TODO file, i.e. to
use the alternative mechanism. Note that, a package contains
libodp-linux implementation can leave the Provides: fields blank, and
actually providing symlinks via the alternative system.
For example:
libodp-generic119: contains libodp-generic.so.119, which is symlinked to
libodp-linux.so.119 via alternatives system.
libodp-dpdk119: contains libodp-dpdk.so.119, which is symlinked to
libodp-linux.so.119 via alternatives system.
No package provides a real libodp-linux.so.119 library.
By doing so you will get rid of the 'package-name-doesnt-match-sonames'
warning, and be able to keep several implementations at the same time.
This situation must be better for your next package.
To implement this, you first need to rename libodp-linux.so.* to match
your package name. Then write some postinst and prerm scripts. Here is a
good example:
https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.postinst.in
https://salsa.debian.org/science-team/openblas/blob/master/debian/libopenblas-base.prerm.in
By looking around in the openblas packaging you'll also find the example
for -dev package.
> libodp-test-utils? These tools are mostly testing programs, that can be
> used either by autotests (in future) or users (to check that their ODP
> installation works).
odp-linux-tools:
-rwxr-xr-x root/root 31016 2018-04-28 14:48 ./usr/lib/odp/linux/examples/odp_l3fwd
-rwxr-xr-x root/root 18504 2018-04-28 14:48 ./usr/lib/odp/linux/examples/odp_pktio
This still look weird. The convention is that -utils/-tools packages
would install executable binaries under /usr/bin (or /usr/sbin in some
cases). I think either of the two solutions will do
* move all the executables to /usr/bin. Their name starts with odp_, so
I don't expect them to pollute the public name space. Putting these
test programs in a private directory just makes it hard to find and
use them.
* provide a script to call all or some of these programs. But you still
need to strip the "examples" substring from the path. User might want
to find human-readable examples in the "examples" directory, but
actually they will end up with a pile of binaries.
> > 10. Why is the package containing
> > ./usr/lib/x86_64-linux-gnu/libodp-linux.so.119.0.0
> > named libodp-generic119?
If libodp-generic.so.119 provides alternative, the shared object can
simply be renamed to libodp-generic.so.SOVERSION.
> > 11. Why is dh_auto_test overrode to empty?
>
> We had issues with make check before, they interacted strangely with
> build environment, that is why it is disabled for now. I plan to
> reenable it later.
How strange is it? And what happend during the test?
As per policy, network access during the build is not availble. If this
is the cause of test problem, we can omit the test part. However, we
should still write the tests in the override_dh_auto_test target, if our
user want to test it somehow.
override_dh_auto_test:
-test_binary
This should be ok.
Reply to: