Re: ANN: cabal-debian et el
"Jeremy Shaw" <jeremy@n-heptane.com> writes:
> Automatically generate a debian directory from a .cabal package. To
> use, cd in the root directory of the .cabal project and run:
>
> cabal-debian --debianize
Also, by default it sets debian/compat to 7, but the build dependency is
on debhelper >> 5. Shouldn't these match?
I get a debian/control with:
Description: The Timber Compiler.
This is a compiler for a strict and pure functional
language
.
Author: Johan Nordlander
Upstream-Maintainer: Johan Nordlander <nordland@csee.ltu.se>
I don't think the Author and Upstream-Maintainer fields should be
embedded in the package description. Maybe they at least need to be
indented by an extra space, to prevent aptitude re-wrapping the lines?
Regarding debian/copyright, there is a proposed machine-readable format
at http://wiki.debian.org/Proposals/CopyrightFormat. You might want to
consider if/how you can leverage that for the default auto-generated
copyright file.
I note that --debianize does not create an .orig tarball or directory
(as uupdate and dmake do). This makes debuild default to building a
native package. debian/changelog also defaults to a native package
version (no "-1" after the upstream version). I'm inclined to think
that native packages are usually a Bad Thing, if only because of the
extra hassle (I'm told) this causes the security team and other NMUers.
Attempting to Debianize QuickCheck2 from hackage resulted in an
unmeetable dependency haskell-mtl-doc. I suggest defaulting to
"haskell-mtl-doc | libghc6-mtl-doc", at least for a blacklist of
packages that are known to currently use the latter form.
When I tried to actually do a "debuild" of quickcheck, I got as far as
the following.
debian/hlibrary.setup build
Preprocessing library QuickCheck-2.1.0.1...
Building QuickCheck-2.1.0.1...
[ 1 of 11] Compiling Test.QuickCheck.Exception (
Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )
Test/QuickCheck/Exception.hs:12:31:
Class `Exception' used as a type
In the type `Exception'
In the type `Either Exception a'
In the type `IO (Either Exception a)'
Test/QuickCheck/Exception.hs:15:36:
Class `Exception' used as a type
In the type `Exception'
In the type `Either Exception a'
In the type `IO (Either Exception a)'
make: *** [build-ghc6-stamp] Error 1
It seems that for this package,
ghc --make Setup
./Setup clean
./Setup configure --global
./Setup build
fails in the same way, but
cabal clean
cabal configure --global
cabal build
does not. I don't know why; I always thought they did much the same
thing.
When I tried cabal-debian --debianize in a clean copy of the Darcs repo
(to test how it handled Haskell apps, as opposed to libs), it printed
Running autoreconf darcs-2.2.0...
This is because though Darcs uses cabal, it still has some legacy
autoconf stuff in its working tree. I don't know doing autoconf stuff
should be considered a Bad Thing.
I notice that for Darcs, the default Build-Depends included
bytestring-mmap and utf8-string packages. These are optional build
dependencies that cabal automatically disables if it can't find, so I'm
not sure if they should be included by default. I guess they should be.
I also note that the Build-Depends field contained a lot of duplication,
e.g.
libghc6-bytestring-mmap-prof (>= 0.2),
libghc6-bytestring-mmap-prof (>= 0.2),
libghc6-bytestring-mmap-prof (>= 0.2),
It might be worth uniquifying the list after you sort it.
Maybe it's just me, but I also prefer the style
Build-Depends:
x,
y,
z
Instead of
Build-Depends: x,
y,
z
The debian/control file correctly included both libdarcs and darcs
packages, but the latter contained only a stub Description field. It
also included two targets that ought not to be included, "witnessess"
and "unit", which are only used by upstream for testing. I don't
suppose there's any way for cabal-darcs to know not to include those.
These executables also default to "Section: misc". I don't know how to
improve on that, unless Hackage/Cabal also has sections.
Description fields are also (AIUI) supposed to be wrapped at 80
characters, rather than whatever was in the foo.cabal file. The common
foo.cabal style seems to result in a much narrower Description field.
For Darcs, it also doesn't correctly detect itemized lists and convert
them to the "debian style" (indent by an extra space, use an asterisk,
no blank lines between items). I don't suppose cabal-darcs can detect
that unless Cabal also standardizes markup within its descriptions.
Whew, that turned out to be longer than I expected! I hope some of it's
useful to you!
Reply to: