Debian library packaging? or, how to get a single deb to work for hugs/ghc/nhc?

Isaac Jones ijones@syntaxpolice.org
29 Jan 2003 12:29:24 -0500


Hi Sven and Martin.  Thanks for your input...

Sven Panne <Sven.Panne@informatik.uni-muenchen.de> writes:

> And recompilation is not always an option, either, e.g. when the
> package in question has some native parts which rely on development
> stuff (headers, program generators, etc.) which is normally not
> installed on the target.

Do you mean, for instance, a package requires Happy to build, but
Happy might not be installed?  In this case, we could make the package
depend on Happy.  Surely this is better than tying each package to a
specific compiler release.

> So we're basically left with two kinds of packages, IMHO:
>=20
>     * Pre-compiled ones, tied to a particular compiler release

And whenever there is a new compiler release for each compiler, all
the package maintainers are going to have to recompile their packages
and upload them, right?  I guess this is pretty OK once stuff gets
into stable, but for unstable I think packages would be broken often,
and for long periods.  This is actually the case with c2hs right now
if I'm not mistaken.

>     * Source packages for "real" developers, not just Haskell users

So for these source packages, do you envision a build system that
registers and rebuilds packages depending on which version of which
compiler you have?

More below...

Martin Sj=F6gren <md9ms@mdstud.chalmers.se> writes:

> The whole idea with binary distribution is to compile things once and
> let others download and install the binary and be done with it.
> Compiling Haskell programs of moderate size on a not-very-recent
> computer takes quite some time, especially if you want to optimize too,
> and will mean a *very slow* installation procedure. That simply is
> unacceptable. Byte-compiling, like e.g. Python does is in my experience
> a lot faster.

I'm not married to the idea of recompiling everything for each user,
but the convenience of having debian and hmake or some build system
figure things out for you seems better since we mostly have lots of
smaller libraries.

So taking Sven's email into account, would you also prefer to see
packages tied to a specific compiler release, then each package
recompiled whenever there is a new release (assuming that this would
be necessary, I'm not sure I'm right about that.)

But this does bring up something that I admit I hadn't really thought
much about: in stable, the new compiler releases won't really be a
problem, but the different compilers (ghc, nhc, hugs) would still be a
problem.

So am I hearing that others would prefer to have packages like:
hunit-ghc5.04.2, hunit-ghc4, hunit-hugs, hunit-nhc, etc?


peace,

isaac