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. Cheers, S.