Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
On 23/05/16 09:18, Gianfranco Costamagna wrote:
Hi Lumin, Ghislain
I think a lot of good progress has been made on the package, bravo
lumin.
An update to this, according to
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
Even if I want to add some testsuite for python-caffe, I don't need
to add those runtime deps in control, I can add them in tests/control
instead, by adding "Depends" field that supprted by d/tests/control.
true, I agree
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.
So yes, the Python runtime dependencies should be part of Build-Depends
and the Python testsuite should be called during the build.
OpenCV 3.0 can yield python3-opencv package with just a small patch,>which is provided by a user in an opencv debian bug.
Protobuf might be similar.
that would be awesome
And I agree, on behalf of the release team I should make python3-*
packages in the initial upload. I decide to bump python from
2 to 3. python3-caffe can be built easily with packages outside
of Debian archive. One of the unapplied patches I removed
is for python3->python2 downgrade reversal.
opencv and protobuf is still on the way of 2 to 3, in Debian.
yes, so lets go for python2
(or maybe lets go for no python bindings?)
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.
Ghislain, do you think we can upload it right now?
even if it doesn't migrate to testing, at least we will have the new
queue trip cleared, and then we can fix bugs on reverse-dependencies.
G.
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?
Ghis
Reply to: