[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian haskell packaging: We're way behind



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 <jgoerzen@complete.org> 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.



Reply to: