[SciPy-user] Debian package(s)?

[eric jones]

> On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote:
> > On Thu, Nov 14, 2002 at 08:57:20PM +0200, Pearu Peterson wrote:
> > > However, I have noticed that few debianized packages either in
their
> > > tar-ball or in their CVS contain debian/ directory containing
> necessary
> > > files for creating deb-files. I was hoping that we could maintain
this
> > > directory inside scipy CVS repository so that debian packaging
burden
> will
> > > be more distributed among developers. The same applies also for
chaco
> and
> > > f2py.
> >
> > 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.  Sometimes (rarely)
> there is outright disagreement about what to put in there, e.g. for
> the dependencies.
> 
> Having debian in the upstream CVS works best when the debian
> maintainer has write access to it.  I do this for one package I
> maintain.  When this issue comes up on the debian mailing lists, the
> concensus opinion is that it is not usually helpful, and sometimes it
> is a nuisance.
> 
> 
> > 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. (?)

scipy_distutils gets used by other things now besides scipy such as
weave and I think Chaco is using it.  It gets bundled automatically by
weave's setup.py into the weave distribution.  Rolling scipy_distutils
into f2py will make f2py a dependency for weave -- not desirable.  But
then neither is the current setup.  

We have three low level packages now: scipy_base, scipy_distutils, and
scipy_test.  Gui_thread might fall into this group also.  A lot of other
packages will depend on one or more of these -- f2py, scipy, weave,
chaco, etc.  It sounding like we really need to bundle the first three
(or four) packages into a separate package (scipy_core?) to ease the
issues with debian packages, rpm's etc.  scipy_core could then be listed
as a dependency by the other packages.

The only thing that makes me hesitate about this is that f2py is
currently pure python.  If we make it depend on scipy_core, the
scipy_base module does have some C modules in it that people will have
to build.  Since f2py really doesn't need any part of scipy_base, this
dependency is a result of how things are packaged.  To get around this,
we could package scipy_distutils and scipy_test together and leave
scipy_base in the scipy package.  Then f2py would only have pure python
modules as dependencies.  Pearu (and others), is this a big win for you,
or would you rather bundle all of them together as a single file?

I'm thinking the windows package will continue to be a single
click-install bundle with everything in it.


eric