Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
- To: Ghislain Vaillant <firstname.lastname@example.org>
- Cc: Gianfranco Costamagna <email@example.com>, firstname.lastname@example.org, debian-science <email@example.com>
- Subject: Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
- From: lumin <firstname.lastname@example.org>
- Date: Thu, 02 Jun 2016 04:33:37 +0000
- Message-id: <[🔎] email@example.com>
- In-reply-to: <5746FAD0.firstname.lastname@example.org>
- References: <email@example.com> <160455514.9893678.1462262603766.JavaMail.firstname.lastname@example.org> <email@example.com> <572DAFEE.firstname.lastname@example.org> <email@example.com> <1214455590.5030779.1463410214107.JavaMail.firstname.lastname@example.org> <573B21AE.email@example.com> <firstname.lastname@example.org> <573B3EDA.email@example.com> <firstname.lastname@example.org> <06DF4AD4-8D14-466E-BAAB-F4C6732D7493@jrtc27.com> <0C30FE13-CCDF-47F8-A0AF-E828717EFEB8@jrtc27.com> <email@example.com> <1708057035.7707250.1463605934134.JavaMail.firstname.lastname@example.org> <email@example.com> <355352132.7885265.1463639538988.JavaMail.firstname.lastname@example.org> <email@example.com> <743933193.1389797.1463991516604.JavaMail.firstname.lastname@example.org> <5746FAD0.email@example.com>
On Thu, 2016-05-26 at 14:32 +0100, Ghislain Vaillant wrote:
> I don't agree. Regarding the testsuite, I believe most features should
> be tested at package build time, including the Python stuff. We want to
> fail early if something goes wrong. To me, the autopkgtest testsuite
> serves a different purpose, i.e. to test that an update in the install
> requirements does not break the currently uploaded package.
Isn't that done by piuparts? confused.
And yes I should also write a python tester script.
> So yes, the Python runtime dependencies should be part of Build-Depends
> and the Python testsuite should be called during the build.
I'll add them later.
> From my experience using caffe at the lab, the Python interface is what
> people are mainly using. So IMO, it would be quite a let down if the
> caffe were uploaded without Python support.
> IMO, it should be either Python 3 alone or Python 2 + 3. I made this
> mistake when packaging OpenGM and regret it now. I'll repeat it here,
> Python 2 has an expiration date and we should encourage people to use
> Python 3.
Let's make python3-caffe-* and let it be python3-only.
> I did not follow all the recent action on the packaging, but why are we
> still using templated install.in files instead of patching the build
> system for the great of the rest of the Linux community?
I indeed made all suggested changes including using `GNUInstallDirs`
to avoid template generation. Currently the *.in files are mostly
fake template (nothing to be replaced) but only
libcaffe-cpu-dev.install.in is the real one. I need to match
a library install directory in this file, which is the only
Oh yes I should rename those non-template files.
BTW, I tested the python3 build and I found that, the python3
version can be built without python3-protobuf, and the compilation
will not crash. Python3 module will be generated but when trying
to import caffe in python3 it will end up with something like:
error import google.protobuf
That is to say python3-protobuf is not a build-dep but a runtime-dep
for the python3 interface.