Hi, On Wed, Feb 08, 2017 at 11:31:10AM +0000, Ghislain Vaillant wrote: > On Wed, 2017-02-08 at 10:58 +0100, Joost van Baal-Ilić wrote: > > On Wed, Feb 08, 2017 at 09:47:08AM +0000, Ghislain Vaillant wrote: > > > On Wed, 2017-02-08 at 10:17 +0100, Daniel Stender wrote: > > > > On 08.02.2017 09:13, Rebecca N. Palmer wrote: > > > > > I have patches for #848764 and #831540; I haven't yet found the cause > > > > > of #831541, but as it only affects big-endian systems, partial > > > > > removal is an option. > > > > > > > > > > However, one of these bugs is a point where upstream plan to make an > > > > > incompatible change (though my fix doesn't), and upstream aren't sure > > > > > whether having Theano in a long-release-cycle distribution such as > > > > > Debian is a good idea: https://github.com/Theano/Theano/issues/5494 > > > > > > On first read, it sounds to me that upstream is failing to understand > > > that having theano in the archive does not replace or substitute > > > traditional development workflow via pip if users want to. > > > > And/or maybe upstream feels anybody using an "obsolete" version of theano > > is doing something wrong. And/or maybe upstream would feel some kind of > > obligation/duty to support users of "obsolete" versions of Debian-shipped > > theano on Debian systems, if Debian were to ship with those. See also the > > xscreensaver debacle, some months ago. I'm just guessing here, > > extrapolating from other upstreams. > > xscreensaver is an application, so upstream's anger was justified since > users had no other (simple) alternative to using the outdated packaged > version.
The xscreensaver situation indeed has some different aspects. > theano is a library, and libraries provided in Debian should be > packaged as redepends for other frameworks / applications . That's why > you are invited to provide a justification in your ITPs as to why > packaging the library for Debian is necessary. > > Unlike with xscreensaver, users do have an alternative for using the > latest theano: fire a virtualenv and use the latest theano there via > `pip install`. > > Same comment for numpy, scipy and the rest of the scientific Python > ecosystem. Anyone using for instance jessie + the system numpy for > serious development is clearly missing out, and should get to know > modern development tools (i.e. venv, pip, anaconda...). Indeed, true, but there's software developers; but there's also people merely _using_ applications depending upon the libraries we're talking about. > > > Our packages are here to support future applications / frameworks, > > > which may require an appropriately packaged theano. Considering the > > > success of deep-learning these days, this prospect is quite likely. > > > > > > > > (Note that their suggested alternative of using pip will involve > > > > > manually installing libblas-dev, as pip only knows about Python > > > > > dependencies.) > > > > Anyway, it would be good to make clear what Debian expects of upstream, and > > how shipping theano with Debian might even be _beneficial_ for upstream. > > Indeed, in the form of dynamic CI (with autopkgtest) and testing on a > variety of architectures they might not have access to otherwise. > Whether they care or not is a different story. > > I believe the easiness of `apt install` which Daniel brought in is no > longer so much of a *strong* argument, now that pip + wheels has become > quite mature. That's my personal opinion though. Thanks for your extra arguments. The for me personally (system administrator at a university) most convincing argument in https://wiki.debian.org/AdvantagesForUpstream is: "Administrators of larger installations can install your software from the official archive and don't need to make special effort to provision your software." And administrators automagically benefit from debian-supplied security upgrades for the software, with zero extra cost. (And then there's also the worth reading https://wiki.debian.org/UpstreamGuide , 'though slightly less applicable for this discussion.) Thanks, Bye, Joost
