Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hello,
2018-05-05 16:47 GMT+03:00 Lumin <cdluminate@gmail.com>:
> 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?
It is not known yet. For previous long term support release we had more than 6
providers. Not all of them are going to be packaged/provided through Debian,
as they were provided by hardware vendors.
> 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.
Unfortunately it is not easy to predict in advance, which
libraries/implementations
will be provided (and when).
I will make my next upload use alternatives, thank you.
> 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.
Quite interesting, thank for the pointer. The idea of generating these scripts
during build time didn't occur to me before.
>> 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.
This looks logical to me. I will move some (usefull) programs to /usr/bin
and will drop the rest of them.
>> > 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.
Some of the validation scripts are trying to create/remove network
interfaces.
> override_dh_auto_test:
> -test_binary
>
> This should be ok.
Ack
--
With best wishes
Dmitry
Reply to: