On 22/08/2010 11:41, Andrew Coppin wrote:
Ivan Lazar Miljenovic wrote:
Hackage has limited support for distro maintainers to state which
packages are available on the distribution. Last I checked, it required
distro maintainers to keep a text file somewhere up to date.
Note that not all distributions bother.
Yeah, I figured. I don't see any Debian or OpenSUSE anywhere, and I know
they do have at least a few pre-built binary packages out there.
It looks as if it's automated for Arch, however. Either that or somebody
is spending an absurd amount of time keeping it manually up to date.
(in particular none of us
involved with packaging Haskell packages for Gentoo can be bothered;
we're slowly cutting back into only keeping packages that will actually
be used rather than all and sundry)
Well, I guess you either manually select which packages to convert, or
you have an automated system convert everything in sight.
This whole observation came about because I noticed that some (but not
all) of my own packages have ended up on Arch, despite being of almost
no use to anybody. I was just curious as to how that happened.
As for why using your distro package manager for Haskell packages is
preferable:
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
Right. So Cabal isn't a package manager because it only manages Haskell
packages? Not sure I agree with that definition. (It also has a laundry
list of problems that can and should be fixed, but won't be.)
I actually spent quite a while trying to figure out what the purpose of
Cabal *is*. It's not like it's hard to download a bunch of Haskell
source code and utter "ghc --make Foo". So why do we even need Cabal in
the first place? The answer, as far as I can tell, is that registering a
library manually is so excruciatingly hard that we actually need a tool
to automate the process. (Obviously when I first started using Haskell,
I was mainly interested in writing runnable programs, not libraries.)
Cabal can also run Haddock for you, which is quite hard. But it wasn't
until cabal-install came along that I even realised that Cabal could
track and resolve dependencies. (The fact that it doesn't track
installed executables is news to me.)
If nothing else, I think that "what Cabal is" should be documented much
more clearly. It took me a hell of a long time to figure this out.
Now, you say it's preferable to use the native package manager where
possible. I've got one word for you: Windows. You know, the most popular
OS on the market? The one installed on 98% of all computers world-wide?
Guess what: no native package manager.
Actually, we have tools that automatically convert Cabal packages to
Debian packages or RPMs or whatever. I think there could be some milage
in a tool that builds Windows installers. (The problem, of course, is
that you have to be able to *build* the library on Windows first!) You
would of course then have all kinds of fun and games with dependency
tracking...
If you look at the original Cabal design document[1], you'll see that
one of the goals of Cabal was to be the glue that lets you convert an
arbitrary Haskell library into a native package for a variety of
systems - including MSIs on Windows. Indeed, I must admit when we were
designing Cabal I thought that native packages would be the most common
way that people would install Cabal packages, specifically because many
systems already have a good package manager, and trying to bypass the
system package manager would be a fundamental mistake. It turned out
that cabal-install would be a lot more useful than I imagined, but the
two systems are complementary: native packages are for installing
globally, and cabal-install is for installing packages in your home
directory.
Even on systems without a package manager (i.e. Windows), it would make
more sense when installing a package globally to build an MSI first, so
that the system can track the installation and let you uninstall it later.
There was a prototype Windows Installer builder for Cabal, cabal2wix [2]
but I think the project is currently dormant.
[1] http://www.haskell.org/cabal/proposal/
[2] http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
