Re: ANN: cabal-debian et el
First of all, apologies for not putting this discussiong directly on
your BTS. I'm bloody lazy and I really hate web UIs. (Yay for
debbugs' bts(1) and roundup's ru(1)!)
On Sat, Apr 04, 2009 at 10:41:55AM -0500, Jeremy Shaw wrote:
>> 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.
Actually on consideration, I'm not sure that these fields should be in
the control file at all. They are supposed to be mentioned in
debian/copyright.
>> 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.
#ubuntu-devel agrees with you regarding use of -0ubuntu11 for packages
that are in Ubuntu first and not in Debian (which I didn't realize).
infinity> twb: But the "only packaged in Ubuntu, and nowhere else"
infinity> case is fuzzy, and sometimes it goes the way of ustrart,
infinity> sometimes it goes the -0ubuntu1 route, generally depending
infinity> on how likely the packager thinks it is that Debian will
infinity> ever pick it up.
infinity>
infinity> twb: (And using versions without "ubuntu" means the archive
infinity> admins have to add a manual blacklist to the sync process
infinity> (we have one for upstart), "just in case" Debian ever ships
infinity> a version)
> 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.
That a reasonable goal, but I would probably try to get something like
-1~unofficial working first, on the basis that it really isn't a
native package.
>> 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.
That's a reasonable position to take.
>> When I tried to actually do a "debuild" of quickcheck, I got as far as
>> the following [...]
>
> IMO, this is a bug in the QuickCheck.cabal file [...]
No worries.
>> 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 don't know, because generating a new .cabal/ tree is too much of a
pain in the arse. Both of those packages are only installed to .cabal
(i.e. --user), so IMO cabal-debian should consider them not installed.
> 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.
Optional build dependencies are currently not handled at all well by
the dpkg/dh infrastructure. What I'm actually doing for another
package is basically this:
Build-Depends: x, y, z,
# These are optional build dependencies that I deem desirable
p, q, r
# These are optional build dependencies that I deem undesirable
Build-Conflicts: a, b, c
I would say that debian-cabal should not care about what's currently
installed -- it should either include ALL optional depenencies by
default, or none of them by default. I think it's desirable to force
the maintainer to decide which optional build dependencies should be
used.
If you can actually detect which dependencies are optional (which I
suspect is a lot harder than it sounds), then I think the clearest
approach is to do this:
Build-Depends: x, y, z
# These remaining dependencies are optional. To exclude them,
# move them into a Build-Conflicts: field
p, q, r
which hopefully makes things very clear to (potentially novice)
maintainers reading the generated debian/control.
>> I also note that the Build-Depends field contained a lot of
>> duplication, [...] It might be worth uniquifying the list after
>> you sort it.
>
> We do: [code...] But, apparently something funny is going on.
You might consider that an "upstream" problem in the darcs.cabal file,
which has a ridiculous amount of duplication :-(
You can get a copy here:
http://darcs.net/darcs.cabal
>> Maybe it's just me, but I also prefer the style [...]
>
> Easy to change, here is the formatting function.
> showDeps xss = [...]
> Not a high priority at the moment.
No worries (re low priority).
>> 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.
Since this is important, I suggest adding a comment to the top of the
debian/control file along the lines of
# Cabal has no concept of "sections", but Debian does. Libraries
# are probably in the correct sections, but it's not possible to
# detect where executables should go. Therefore please change
# "Section: misc" below to the appropriate section. The list of
# valid sections is in the Debian Policy manual, at <URL>.
...if the package contains executables.
Indeed, on the basis that debian-cabal's output is only a draft that
will be reviewed by a human, lots of commentary is generally a good
thing.
Reply to: