[Haskell-cafe] Library Process (was Building "production stable"
software in Haskell)
sven.panne at aedion.de
Tue Sep 18 13:24:08 EDT 2007
On Tuesday 18 September 2007 09:44, Dominic Steinitz wrote:
> This discussion has sparked a question in my mind:
> What is the process for the inclusion of modules / packages in ghc, hugs
> and other compilers & interpreters?
Personal interest of the people working on GHC et. al. ;-)
> I thought the master plan was that less would come with the compiler /
> interpreter and the user would install packages using cabal. [...]
Although this statement might be a bit heretical on this list, I'll have to
repeat myself again that Cabal, cabal-install, cabal-whatever will *never* be
the right tool for the end user to install Haskell packages on platforms with
their own packaging systems like RPM (the same holds for other systems, I
just use RPM as an example here). This packaging system, and nothing else,
will write into my /usr, otherwise chaos and versioning hell will threaten
the system integrity. Cabal is a very fine tool to be used from RPM .spec
files and to develop below one's own home directory, but it is not the tool
of choice for the final installation. There are various reasons for this:
* Imagine you want to find out to which package in which version a given
file belongs. Impossible, if RPM is bypassed.
* RPM offers functionality to verify the integrity of the installed SW, it
can tell me which files are documentation, which ones are configuration
files, etc. All this meta information has to be in a single system.
* YaST, yum, etc. already have the notion of repositories, trust (via
standard cryptographic methods) and resolving transitive dependencies, so we
would re-implement things which are already there, well maintained and
well-known to end users.
* Imagine every language would force their end users to use specific tools
for installation, this would be ridiculous. Personally I don't care at all
about the details how Perl modules, some PHP/Python/... libraries etc. are
installed on my system. This knowledge belongs to the packager who builds a
nice RPM, mentioning all dependencies, so my favourite RPM tool can
transitively resolve, download and install everything, offering a nice GUI if
I like. No need to remember how to do this for Perl/PHP/Python/etc.
Regarding the pros and cons of small, separate packages: In general I agree
that this is the right direction, and this is what other languages do as
well. There are e.g. tons of Perl/PHP/Python/Ruby RPMs available for my
system, each offering a specific library, while the RPMs containing the
interpreters/compilers are rather small. But: IMHO we are not there yet,
because we still have to remove quite a few rough edges until we can smoothly
offer e.g. an RPM repository with lots of small library RPMs (Cabal
versionitis, updating the Haddock documentation index, etc.). Therefore, I'll
continue to offer only "Sumo-style" RPMs for GHC + boot-libs + extra-libs for
now, but I hope I can change this in the future.
Another point: Although this is hard to believe nowadays, ;-) people are not
always online, so "simply" installing what is missing might not always be an
option. "Great, I'd really need the foobar-2.1 package now, but I'm currently
10000 feet above the Atlantic ocean..." The right way to tackle this problem
is using meta packages, basically referencing lots of bundled small packages.
RPM offers such a feature, and I guess other systems, too. On a laptop, such
a meta package leading to the installation of tons of libraries is the right
approach, on a fixed workstation the story might be different.
More information about the Haskell-Cafe