
Ketil Malde
Achim Schneider
writes: Caveat: I have only a vague grasp on what exactly is being criticized here - using a modern Linux distribution, tons of packages are available, and almost all issues Claus point out seem to be taken care of - at least as far as I can see.
Well, then there are developers who don't want to do .ebuilds, .rpms for 20 distributions, .debs for 20 distributions, .cabs... Meaning that if you have a project with 5 developers using 3 1/2 distributions, you will have a hard time installing.
I think you should either require your developers to use the system that is provided to them, or be able and willing to maintain their own system. Most large Linux distributions seem to come with lots of Haskell-related stuff nowadays - 139 packages on my Ubuntu install (divide by something close to 3, as most library stuff comes in -dev, -doc and -prof variants).
Well, you have a point but still don't have one. Many of gentoo's haskell .ebuilds are seriously outdated, eg. wxhaskell still depends on ghc 6.4. See "Damnit, we need a CPAN" The haskell overlay features about 240 packages from alex to yi, hackage currently lists 596 packages. There are always things that a distribution doesn't include, especially sparsely used special purpose software. Compiling a LADSPA plugin by hand isn't that much of an issue, but you'll get into problems as soon as you want your programs to find it without touching paths that only your system's package manager should touch. I'm proud to say that my current gentoo installation is still the first one, surviving several world updates and at least 4 years of hacking around, using a lot of unstable and masked packages.
You have a point, though, and I wouldn't mind at all cabal-install being integrated into portage,
I'm not too familiar with portage, but I think a better solution is to provide tools to automatically generate packages for the various systems. How would you specify dependencies on non-haskell components in a portable way?
By using portage ;) Seriously: Gentoo isn't a distribution, but a meta-distribution. It wouldn't make much sense to support the generation of alien binary packages, though, as dependency names will surely differ, and if you have to generate the whole distribution, you can equally well just use portage to install it. Regarding non-haskell dependencies: It's already a problem from distribution to distribution. In portage, you would have to depend on e.g. either gtk+ or emul-linux-x86-gtklibs (if you want to build 32bit software...), in debian on gtk-dev. Each distribution would have to make a list on how cabal's non-haskell dependencies map to their own package names, which is seriously less work than figuring these out by hand. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.