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

Re: I'd like to help out.

At Thu, 19 Mar 2009 12:03:58 +1100,
Trent W. Buck wrote:
> "Jeremy Shaw" <jeremy@n-heptane.com> writes:

> That may be fine for a third-party repo, but when I last looked at the
> results (perhaps a month ago) from the cabal-debian in hackage, ISTR
> they were full of lintian errors and warnings.  For example, ISTR the
> package descriptions of the -doc and -prof packages did not reproduce
> the long description, they merely all had the same string along the
> lines of

I don't fundamentally disagree with this. A key goal of cabal-debian
is to make it very easy to generate high-quality, policy compliant
debian packages from cabalized Haskell libraries.

There are three classes of issues to deal with:

 1. bugs that are really due to haskell-devscripts / hlibrary.mk

  These affect cabal-debian, but the fix obviously needs to be made to
  haskell-devscripts or hlibrary.mk.

 2. failure of cabal-debian to follow policy / lintian even though it could

  For example, right now it generates -doc packages with the name,
  libghc6-package-doc instead of haskell-package-doc. That is
  definitely fixable and will be fixed.

 3. things that cabal-debian will never be able to

  If the original .cabal package does not have a good long
  description, cabal-debian certainly can't write one. So, creating
  Debian quality packages will almost always involve a bit of
  handholding and fixup by the Debian maintainer.

  Currently it is easy to generate the initial package, and then do
  any required fix up by hand. More challenging is to make it easy for
  the maintainer to update to a newer upstream release. Automatically
  merging the old and new control files is pretty darn tricky to do in
  a reliable and automated way. So currently cabal-debian just
  generates a control.new and leaves it up to the maintainer to do the
  merge by hand. Clearly something most sophisticated could be done.

For the near term, I think the focus is mostly addressing any  policy
compliance issues so that cabal-debian generates the best possible
starting point so that a maintainer has to do the least amount of

Actually, right before that is making sure that the version in darcs
builds using the latest packages from Debian.

- jeremy

Reply to: