Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
- To: lumin <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: Ghislain Vaillant <firstname.lastname@example.org>
- Date: Thu, 2 Jun 2016 08:00:36 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <[🔎] 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> <[🔎] firstname.lastname@example.org>
On 02/06/16 05:33, lumin wrote:
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.
The build time testsuite, autopkgtest and piuparts serve different
purposes. You might want to spend some time reading a bit more about
those, as the distinction is quite important from a maintainer's point-
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
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.
Don't forget to forward the patch upstream please.
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.
It is explicitly listed in the requirements , so no surprise here.
Since you intend to run the Python testsuite at build time, you will
probably need all these dependencies translated to Build-Depends.