Library Infrastructure Proposal & Home Page

[Isaac Jones]

Sorry I haven't gotten around to replying to everyone's comments.
I've been shifting apartments :)

"Simon Marlow" <simonmar at microsoft.com> writes:

> I think the proposal is great.

Thanks!

> It might be worth saying earlier on that the library infrastructure is
> expected to be a layer underneath the platform's native package support
> (if such support exists).

Good point.  Thanks.

> FreeBSD's ports is both a source and binary package system.  A FreeBSD
> system functions perfectly well using only binary packages.  

I see.  Can you give me a light summary of what a binary package for
BSD looks like?  Do people distribute binary packages on their web
sites?

> FreeBSD (in source or binary mode), and Gentoo, have no support for
> recompiling packages when something they depend on has changed.  This is
> the biggest failing of these systems IMHO.  The 3rd paragraph of 2.1
> therefore isn't correct - 

I think I made it clear in the next paragraph that this is still a
problem in FreeBSD, but I'm only suggesting that the end user actually
has a reasonable _solution_ for a source distribution.  In a binary
distribution, the user either has to download the source (package) and
recompile themselves, or wait for the maintainer to do it.

However, your point about FreeBSD having binary packages may make all
of that false.

> there's still a big problem for source-based distributions. However,
> this is not *our* problem, it's theirs - when a dependency is
> updated, everything that depends on it should be recompiled.

In fact, I was recently thinking that binary distributions like Debian
should have some support for a recompilation: a package should be able
to declare that it has this special "recompile" dependency on ghc /
nhc / xemacs / gnuEmacs, and when a new version of the compiler is
uploaded to the autobuilders, they should go out and recompile all the
packages.  Instead, Lisp, Elisp, and Haskell all have to roll their
own solutions for roughly the same problem.

> ./Setup.lhs bdist:  wouldn't it be better to create a source RPM than a
> binary RPM?

That's a good point.

> Once you have a source RPM the RPM tools can be used to build a
> binary RPM.  Similarly for FreeBSD and Gentoo - I'd expect Setup.lhs
> to produce a port skeleton/ebuild for me, not a binary package.

That is what the prototype does for Debian; it creates the skeleton
for the user to edit and build the binary distribution from, except
that it does actually go ahead and build the binary distribution, for
better or worse.

> The PackageConfig file:  I'd leave out 'provides' and 'isDefault' unless
> we have a convincing example which needs them.  

Actually, I consider the Haskell Implementations themselves to be the
best example: we want a way to say that libraries depend on having a
Haskell98 (or Haskell04 ;) ) Implementation installed, and we want to
be able to track the default Haskell Implementation.  Perhaps this
should be built into the system, but I think it has more general
applicability.

For instance, if we had that common GUI API that was discussed at
ICFP, and there were several implementations of it (one for Windows,
one for Gnome, one for TCL or whatever), then a package could depend
on having "something that implements the GUI API", rather than a
particular package.

> Possibly add: 'haddock_html_root :: String' and 'haddock_interface
> :: String' for documentation.  

I definitely like that idea.

> I'm thinking about removing 'extra_ghc_opts' - it's highly dodgy
> when combined with 'auto'.

I'll remove it from the proposal for now, and I'm going to add this text:

    I propose that implementation-specific fields be prepended with
    the implementation name: ghc_interpreter_flags,
    hugs_interpreter_flags, etc.

> I agree with Ross's comments about data vs. code.  Let's abstract as
> much as possible as data.

What did you think about my points in the followup post.  I definitely
agree that we want to leverage this data, but there are a variety of
ways to do it!


peace,

isaac