Re: ANN: cabal-debian et el
At Sat, 04 Apr 2009 13:14:29 +1100,
Trent W. Buck wrote:
> Also, by default it sets debian/compat to 7, but the build dependency is
> on debhelper >> 5. Shouldn't these match?
Fixed in darcs.
> 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?
Fixed in darcs.
For now, I added the extra space to avoid re-linewrapping. It's easy
to stop adding those lines if people don't want them.
> 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.
Added a bug:
http://bugzilla.seereason.com/cgi-bin/bugzilla/show_bug.cgi?id=242
> 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.
http://bugzilla.seereason.com/cgi-bin/bugzilla/show_bug.cgi?id=243
If you provide a .orig file, it will be used, but you are correct that
one is not automatically created.
> debian/changelog also defaults to a native package version (no "-1"
> after the upstream version).
I am not quite sure what the best thing to do here is. For Debian,
defaulting to -1 seems like the best choice. But, for Ubuntu, I
believe the best default would be, -0ubuntu1. And for distributions
that derive from ubuntu, -0ubuntu0seereason1.
If a non-maintainer is using cabal-debian to generate .debs for their
local system, the current default has the advantage that it will sort
lower than and official debs generated for their distro.
http://bugzilla.seereason.com/cgi-bin/bugzilla/show_bug.cgi?id=244
> 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.
How long will this situation exist? If the goal is to have everything
renamed to haskell-.*-doc by the time things are transitioned into
testing, then I am inclined to leave things alone. If not, this is a
pretty easy change to make.
The current code does a mechanism in place for picking the correct
prefix on a per package basis, though it is not currently being used
(nor is it very sophisticated).
> 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.
IMO, this is a bug in the QuickCheck.cabal file. If you change:
Build-depends: base >= 3, random
to:
Build-depends: base >= 3 && <4, random
Things should work. This is outside the scope of cabal-debian.
> 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.
It is something that is explicitly done in the cabal-debian
code. (Debian.hs contains a function, autoreconf, which is generating
those messages). I didn't write the code, so I have no idea what is
going on or why. But, it appears that someone thought it was the right
thing to do.
> 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.
If you don't have them installed when you run cabal-debian, what
happens? I am tempted to think that cabal-debian won't add depends for
them. I am not sure if that is good thing or bad thing either.
> 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.
We do:
mergeDeps :: D.Relations -> D.Relations -> D.Relations
mergeDeps x y =
nub $ foldr insertDep x y
But, apparently something funny is going on.
http://bugzilla.seereason.com/cgi-bin/bugzilla/show_bug.cgi?id=245
> Maybe it's just me, but I also prefer the style
>
> Build-Depends:
> x,
> y,
> z
>
> Instead of
>
> Build-Depends: x,
> y,
> z
Easy to change, here is the formatting function.
showDeps xss = intercalate ", " (map (intercalate " | " . map show) xss)
showDeps' prefix xss =
intercalate (",\n " ++ prefix') (map (intercalate " | " . map show) xss)
where prefix' = map (\ _ -> ' ') prefix
Not a high priority at the moment.
> 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.
Yeah. Fortunately, it is easy to delete the extra paragraphs, and
update the Section. That is probably the best we can hope for unless
.cabal starts providing extra information.
> 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.
Yeah, this type of stuff is why we can't entirely replace the Debian
Developers by a very small shell script :p
Thanks for all your feedback! Feel free to add more information to the
bugs, or submit patches for any open issues that you really want to
see fixed.
- jeremy
Reply to: