Don Stewart <d...@galois.com> writes: > allbery: >> Supposedly a future Cabal extension will be to, instead of installing, >> write out a package for a vendor packaging system (yum, apt, yast, what >> have you). Consider contributing to that effort. >> > > However, we have tools for some distros that do this, and some distro > tools support it directly (e.g. "bauerbill --hackage" on Arch Linux > knows how to ask cabal2arch to translate the .cabal file). > > Contribut to yum to allow pulling from hackage, by calling cabal2yum?
In general, I think this is a bad idea. I don't know how it is in Arch, but for Gentoo we need to do a lot of QA'ing to make sure our ebuilds generated with hackport work properly (which is one reason why we don't churn ebuilds out as fast as you generate PKBUILDs). Part of the problem is probably that hackport isn't as polished as cabal2arch, but a few other concerns we need to take care of are: 1) Gentoo has categories for packages; whilst for Haskell stuff we can usually correctly guess dev-haskell/ as the category, there are a few exceptions (e.g. pandoc is in app-text/). This is an even bigger problem when dealing with C deps, etc. 2) Dealing with flags: in most cases, we expose the Cabal flags as USE flags, so we need to take care of getting all those dependencies right. 3) Multiple versions: we have to take care of supporting multiple versions of GHC, as well as different versions of QuickCheck, etc. It doesn't help that due to the limitations of portage, Gentoo ebuilds do not support proper ranged dependencies. However, this is most probably not an issue for most distributions where users get given one version of a specific package and they'll shut up and accept it. 4) It has to build always: related to the above, because we don't provide binaries, we have to ensure that packages are built reliably in a multitude of situations. We recently had the situation where for some reason GHC 6.12.2 would build for someone but then wouldn't actually run; we eventually tracked down the problem to his usage of ccache: as of 6.12.2, the GHC wrapper script hardcodes which C compiler it was built with, and as ccache was only used when building packages the path to the C compiler in the GHC wrapper script was incorrect (so all our hacks to get this new "feature" of GHC working properly when users bootstrap had to be scrapped as they made the situation even worse in this case). Again, these situations are mainly Gentoo-specific due to the unique nature of the distribution (though distributions without categories still have to ensure the Cabal-package-name-to-distribution-package-name mapping is consistent and correct). I would, however, imagine that in general having end users use their package manager attempt to automagically integrate Hackage packages into system packages would be fraught with peril. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe