Hello, 2018-05-05 16:47 GMT+03:00 Lumin <cdlumin...@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
