On Wed, May 23, 2018 at 07:50:57PM +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > I have updated odp & odp-dpdk packages on mentors.d.n. Please file another RFS bug for the odp-dpdk package since it is a different source. > 2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>: > > I will make my next upload use alternatives, thank you. > > This upload uses alternatives to select ODP library to be used. The package is going in the right way, but the alternatives still needs to be improved. > >> * 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. > > I have moved several executables to /usr/bin and removed the rest of them. > > This upload does not have manpages for those binaries, I will fix that in > the next upload. Reasonable. > >>> > 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 > > This is not fixed yet. Also will be fixed in the next upload. OK. Once you have managed to add working tests, adding autopkgtest test cases is recommended. Debian's infrastructure will run these tests regularly to make sure there is no problem that are easy to detect. > Could you please review alternatives system, so that I can be sure that > I've used them correctly? > > -- > With best wishes > Dmitry Nitpickings about the updated package: 1. README.Debian "Library packages should contain libodp-linux.so.FOO" It should be "libodp-linux.so.SOVER", which is more precise. 2. command `dot` comes from graphviz, but it is missing from B-D. 3. libodp-generic119 should provide libodp-linux.so.119 instead of libodp-linux119. And applications that need libodp-linux.so.119 could declare Depends: libodp-linux.so.119 | libodp-generic119 . This is similar to libblas.so.3 | libblas3 setting of the BLAS implementations. 4. libodp-generic-dev should Privides: libodp-linux.so . odp-generic/libodp-linux.so should be registered in the alternatives system to provide a /usr/lib/DEB_HOST_MULTIARCH/libodp-linux.so . The static library /usr/lib/x86_64-linux-gnu/libodp-linux.a should be put to the /.../odp-generic directory, and be registered as a slave of the libodp-linux.so alternative. I also noticed that the symlink points to an invalid path. Please solve this issue by the alternatives system as said above. root@bfb95763d3d6 ~/odp-1.19.0.1# ll /usr/lib/x86_64-linux-gnu/libodp-linux.so lrwxrwxrwx 1 root root 23 May 23 16:01 /usr/lib/x86_64-linux-gnu/libodp-linux.so -> libodp-linux.so.119.0.1 libblas3 and libopenblas-base and their corresponding -dev packages are good examples at this point. If you have doubts, you can carefully examine these packages which may possibly provide help. Please ping me if you have question, or ready for the next round of review :-)
Attachment:
signature.asc
Description: PGP signature