> > Having a single package database for all Haskell
> implementations seems a
> > hard thing to implement: when GHC is installed, it will
> have to check
> > whether the database and haskell-config already exist, and
> similarly for
> > the other Haskell implementations. When a Haskell system is
> > deinstalled, it has to decide whether to de-isntall
> haskell-config and
> > the package database.
>
> I don't think that's so bad. Figuring out if a package database
> already exists should be a matter of having an agreed upon
> System.Directory.systemConfigDir. Then maybe the package database
> itself can tell you where to find haskell-config.
What about multiple versions of GHC installed on a system, each with
different sets of packages installed? Can I still install GHC in my own
home directory, without needing to modify files in /etc?
> I think that the compilers / interpreters installed on the system will
> also be stored in the "package config" database. If you're
> deinstalling yourself, the package database can tell you whether
> you're the only compiler left and thus whether to get rid of
> haskell-config.
>
> That said, I think there are still issues with having a single package
> database, for instance, what if a package configuration for one
> Haskell Implementation has a field that conflicts with the package
> configuration for another implementation. Yuck! But maybe that won't
> come up. For instance, right now there are separate flags for ghc,
> nhc, and hugs opts, and probably there should be flags for
> shared opts.
Also, there doesn't seem to be provision in the package configuration
for naming libraries specific to a particular implementation (eg. to use
this package on GHC you must link in libHSwibble.a from /foo/bar, but on
nhc98 you link in libHSnhc_wibble.a from ...). It seems to me that
every field needs to be duplicated for each compiler installation;
either that or you could put the compiler name in the package
identifier, so you'd have packages like "ghc-6.2-base-1.0",
"nhc98-1.3-base-1.0".
Incedentally, GHC never uses the extra_ghc_opts in the package
configuration. In fact, I don't think it should be there: it doesn't
make sense in conjunction with auto packages (if I don't know whether
I'm using a package or not, I don't know whether to add the flags). The
flags fields should be disabled if auto is True.
> > I'd rather just admit that the Haskell systems are
> separate, and each
> > provides its own implementation of Distribution.Package. Yes, this
> > means that if you run Setup.lhs with Hugs it is different
> than running
> > it with GHCi: if I want to install a package for GHC I
> have to run the
> > Setup.lhs script using GHC.
>
> I think this would dash my hopes of being able to install a package
> with a single command. The idea so far has been to have some kind of
> haskell-interactive / runhugs-type executable /usr/bin/haskell which
> will execute the setup script to install and configure the package
> based on the already-installed compilers.
It doesn't prevent you doing this. Here's how it might work:
- Each compiler has their own package database, and their own
implementation of Distribution.Package with an
implementation-defined location for the package database(s).
- There is a suite of tools, including haskell-config and
/usr/bin/haskell, which are installed only once.
These tools know about all the installed compilers on the
system. We could install these tools with a compiler, or
separately; installs/deinstalls of compilers need to update
some state so that the tools are aware.
- /usr/bin/haskell could run the script it is given using
each compiler on the system, if that's what you want. eg.
$ /usr/bin/haskell script.hs
-- runs script.hs using the default compiler
$ /usr/bin/haskell --all script.hs
-- runs the script using each compiler on the system
so to do an installation for all compilers, you say
'./Setup.lhs --all --install', assuming that Setup.lhs begins with
'!#/usr/bin/haskell'.
> Likewise, when you install a new compiler, it knows about what
> packages are there already for the other ones and might take a crack
> at building them for itself.
>
> This isn't so far fetched: elisp for emacs and xemacs already do
> something similar on Debian at least.
We can aim for this in the long term if you like - I still believe this
is something that the package management system should do for us,
though. The end result is the same, and it's a lot less work.
Cheers,
Simon
