Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Dear all,
On 16/05/16 15:50, Gianfranco Costamagna wrote:
Hi Lumin
Done. Updated package has been uploaded to mentors:
https://mentors.debian.net/package/caffe
1) did you try to enable the Debug build too?
without CMAKE_BUILD_TYPE=RelWithDebInfo you won't be able to get automatic debug packages I think
I don't think it is true (anymore?), since Debian injects its own "None"
build configuration + DEB_*_MAINT_FLAGS.
2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible
I would prefer a python3-only build
Same here. Since the build system leaves you the choice, please consider
packaging the Python 3 version. Python 2 has an expiration date anyway.
3) all the "debian/tmp" strings in install files should/can be removed I guess
Indeed, they should probably be removed.
(I didn't review all the packaging, just something that might/should be fixed.
I'll wait for Ghislain to finish his review ;)
* I am really not a fan of the templated configuration of the dh_install
files. Worst case, do it programmatically in d/rules rather than
declaratively with templates + a call to yet another custom script.
AFAIC, this creates a lot of overhead for no obvious benefits from a
team-maintenance point-of-view.
* Thinking long-term solution, one should just bite the bullet and make
the build system multi-arch aware. It's just one module in CMake
(GnuInstallDirs) and substituting hardcoded DESTINATION paths with the
appropriate CMake variables. I am sure upstream would accept such patch,
and all distributions could benefit from it. I have done it multiple
times and never encountered resistance upstream. Plus the significant
simplification of the debian files...
* On a different note, caffe seems to support building the documentation
from source with doxygen. Please consider packaging it in a separate
binary package (caffe-doc). The content of examples/* and models/*
might also fit in this -doc package.
* You should consider adding a packaging testsuite. You could start with
a script running part or all the examples shipped in the -doc package,
which would verify that the packaged software run as intended.
* You should consider adding some upstream metadata as described in [1].
I am sure the Caffe guys would appreciate that we appropriately forward
the citation information displayed on their README.
* What is the purpose of keeping unapplied patches in d/patches?
* Missing uversionmangling in d/watch for appropriate tracking of
release candidate releases.
* Consider using libblas-dev | libblas.so as Build-Depends instead of
libopenblas-dev. Not everyone is using openblas as its prefered blas
implementation and upstream does not force to use this specific vendor
(do they?), so no reason to force it here either.
* For the future, seems like additional caffe-tools and octave-caffe
binary packages could be created from the content generated by the
matlab/ and tools/ leaves of the source tree. I guess that's what is
acknowledged in debian/TODO.
[1] https://wiki.debian.org/UpstreamMetadata
Ghis
Reply to: