[Haskell-cafe] RE: Definition of the Haskell standard library
duncan.coutts at worc.ox.ac.uk
Sat Sep 1 20:00:51 EDT 2007
On Sat, 2007-09-01 at 18:47 +0200, Sven Panne wrote:
> On Tuesday 31 July 2007 19:39, Duncan Coutts wrote:
> > [...]
> > The docs for those packages would be available for packages installed
> > via cabal (assuming the user did the optional haddock step) and would
> > link to each other.
> Well, on a normal Linux distro a user should *never* have to call cabal (or
> any of its cousins) directly, the distro's package manager should be the used
> instead. On an e.g. RPM system, the .spec file would use Cabal to e.g.
> (un-)register a package, because RPM has to know what is installed, which
> other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal
> should not try to mirror a full-fledged package system, simply because on
> every (non-Windows ;-) platform there are tons of native tools for this
> purpose, and Cabal is not "in the driver's seat" when it comes to SW
I think it's inevitable that there will always be a mixture of packages
that are managed by the system package manager and ones that are too
insignificant to be packaged by the distro. So cabal-install should
cooperate with the system package manager somehow.
Another strategy would be to have tools that the users can use to
generate system packages from cabal packages and then install those via
the system package manager. We already have such tools for rpm and
gentoo ebuilds. Again, these would be for the case of less significant
package that the distro does not package itself. For example, gentoo has
a tool that can be used to install perl CPAN packages via the system
package manager, since there are many 1000's of CPAN packages and only a
few hundred of those are included in the main portage collection.
There are other cases not covered by system package managers, like
unprivileged user installations under $HOME.
> > The problem with generating one of those is what manages it? What
> > package would it belong to etc.
> Of course we are not the first project to face this kind of problem: Texinfo
> offers a central contents page as well. To maintain this page, it comes with
> A "install-haddock" tool would be the solution IMHO.
That re-generates the index page, right.
Perhaps haddock itself should be extended with this ability. All it
should need to do is read all the .haddock files that ghc-pkg knows
about and generate the index page from that. I assume the .haddock files
contain enough information to do this, or it could be modified to
More information about the cabal-devel