John, that's a good list. Here's what we have at SeeReason that fits in. You are welcome to any or all of it.
The cabal-debian tool converts from Cabal -> Debian format. It's dependency analyzer is not very clever. The autobuilder builds full repositories. It's input specification is pretty powerful. You can point it at upstream repositories of various types (darcs, cvs, svn, tarballs, ...) and specify accompanying patches to be applied. http://src.seereason.com/cabal-debian http://src.seereason.com/autobuilder Supporting libraries (I may have missed some): http://src.seereason.com/haskell-devscripts-cdbs/ http://src.seereason.com/haskell-debian-3/ http://src.seereason.com/haskell-unixutils/ Directories with autobuilder targets. Many just have patches that get applied with quilt or cdbs when the autobuilder fetches the source from upstream. http://src.seereason.com/quilt/ http://src.seereason.com/debian/ More detailed responses about the capabilities below: On Thu, Jan 15, 2009 at 10:47 AM, John Goerzen <[email protected]>wrote: > I'm noticing on the haskell-cafe list that Arch Linux has 827 Haskell > packages. > > I'm CCing Don Stewart because he's the one that listed that figure, and > has also been passively goading me to do something about the situation > in Debian ;-) > > What are the major challenges towards being able to automatically > convert Hackage/Cabal packages into Debian source packages? I'd imagine > they are: > > 1) Identifying the Debian package names/versions for the Cabal build-deps We do that in cabal-debian. I sincerely doubt that it is bug free, but it does a reasonable job. > 2) Identifying the non-Haskell build-deps for packages that are things > like C bindings I forget if we handle this one. > > 3) Correctly pulling out license and copyright information I think we did the obvious thing, but often it doesn't work, that is Cabal files often don't have the correct specification. > > > 4) Being able to rebuild binaries on a mass scale when the packages they > depend upon are rebuilt, or when GHC itself is rebuilt Yes, our autobuilder does that. > > 5) Identifying which packages can have Hugs packages built Some work on this, but we don't use them. > > 6) Preserving all of the above knowledge across upgrades We do that with the cdbs and quilt style diffs for packages. > > 7) Automatically identifying what is out-of-date vs. Hackage We do not do this yet. > > > 8) Figuring out whether new Hackage uploads should be uploaded to > Debian. Example: the latest HaXml on Hackage is not a stable release. Definitely do not do this.
