[SciPy-user] Debian package(s)

[Pearu Peterson]

On Thu, 14 Nov 2002, Steve M. Robbins wrote:

> On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote:
> > That could be nice, but have in mind that it is always the Debian developer
> > who has to decide the correct debian scripts. So, including a debian/
> > directory in distribution could be a bit of a mess if developer decides to
> > change something. Maybe Steve can give his opinion on that.
> 
> Having the debian directory in upstream CVS can be useful for those
> who don't want to use packages from the debian servers.  
> 
> However, as Francesc alluded to, the upstream debian directory could
> diverge from what appears in the "official" debian package, which
> reduces its value, somewhat.  There are a variety of reasons for the
> divergence.  Often, especially when the debian maintainer is not one
> of the upstream developers, it just bit-rots.

This "bit-rots" is exactly why I thought why it would be preferable if
debian/ directory would be under the control of SciPy CVS.
I think that SciPy will change in future quite a bit so that debian/
scripts written today will probably need active maintainence also in
future. If someone is willing to do that, then either way (having
debian/ in Scipy CVS or not) is fine with me.

> > Anyway, if "before Christmas 2002" is a tentative date for releasing scipy
> > 0.2, let's start working right now in debian package to be able to publish
> > it at the same time than 0.2 announce (testing well the debian package would
> > consume a few weeks).
> 
> Sounds good.  Don't forget f2py.  Scipy will need to build-depend on
> it, so it needs to be packaged first.  
> 
> We had a discussion about f2py, scipy, and "scipy_distutils" back
> in August, starting at:
>   http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002-August/001109.html
> 
> Unless things have changed recently, the problem is that both f2py and
> scipy want to install scipy_distutils.  I think the suggestion was
> that f2py sources should build the scipy_distutils package, and that
> scipy should not.  This might need some fiddling in debian/rules to
> prevent scipy from installing it.
> 
> I'm a little muddled now as to when and how the scipy_distutils gets
> used.  I think that f2py uses those files at runtime.  So they have to
> be installed when building scipy (i.e. when running f2py).  But I
> recall someone claiming that scipy doesn't need the distutils at
> runtime. (?)

Here follows some hard facts that set few restrictions for packaging the
related tools:

1) f2py install does not require scipy_distutils. f2py ships and installs
scipy_distutils only for the convinience of f2py users (that may not be
scipy users).
2) Usage of f2py requires scipy_distutils installed.
3) scipy install requires f2py and also scipy_distutils, but the later
needs not to be installed as the scipy setup.py script finds it in the
current directory, and also f2py would use that.
4) Usage of scipy does not require scipy_distutils nor f2py, at least not
currently.

It is difficult to say what would be the most appropiate way to debianize
scipy and tools without trying something out first. Anyway, may I suggest
the following policy as a starting point:

1) scipy_distutils
build dependencies: python-dev
testing dependencies: scipy_test (not implemented, will it ever be?)
runtime dependencies: python-dev

2) f2py2e
build dependencies: python-dev
testing dependecies: scipy_test, scipy_distutils, Numeric
runtime dependencies: scipy_distutils, Numeric

3) scipy
build dependencies: scipy_distutils, f2py2e, atlas2-headers, atlas2-base
                    atlas2-base-dev
testing dependecies: scipy_test, Numeric, atlas2-base
runtime dependencies: scipy_base, Numeric, atlas2-base

4) scipy_base
build dependencies: scipy_distutils, Numeric
testing dependecies: scipy_test, Numeric
runtime dependencies: python, Numeric

5) scipy_test
build dependencies: scipy_distutils
testing dependecies: python, Numeric
runtime dependencies: python, Numeric

Notes:
* There is a possible chicken-egg problem with scipy_test and
  scipy_distutils. One way to solve it by introducing some
  super-package that contains both scipy_test and scipy_distutils.
* scipy_base is for those who wish to install only few modules from scipy 
  separately. However, as a first instance, scipy_base could be
  installed under scipy, or with scipy_test and scipy_distutils in this 
  super-package.
* There are also weave and chaco packages. Currently weave is installed
  both as a separate module and as a submodule of scipy. I would suggest
  dropping the latter. Eric, what do you think?
  And I am not sure how far chaco is. Is it anywhere ready to be released
  with scipy 0.2?
* "Testing dependencies" means that it should work both when the package
  is installed and imported to python, or not installed but run inside the
  source directory.

HTH,
	Pearu