I've just uploaded haddock 2.4.1-1, ghc6 6.10.1-1 and a new build of
mtl library to experimental.
Haddock wants to be built with the same version of GHC that it
generates documents for. "Haddock's internal GHC version must match
the configured GHC version", as it says. That means that, when it's
time to push this into unstable, I'll need to:
1) upload haddock and have it build against ghc 6.8.2
2) upload ghc6, which has a build dep on haddock (>= 2.4.1)
3) upload haddock again, so that it's built with ghc 6.10.1
4) upload ghc6 again, so that ghc6-doc gets built correctly
The first step is probably unnecessary, but I'd like to stick haddock
(>= 2.4.1) as a build dep for ghc6 right away.
After 4) is done, you're free to upload libraries to unstable. I'm
not going to coordinate this kind of a transition with experimental.
My arch is i386 and I've built haddock with ghc 6.10.1 for that, but
you may need to repeat the above steps if your arch is different.
Most likely I'll need to do new uploads of haddock and ghc6 to
experimental anyway, which would take care of this.
Given haddock's pickiness, it looks like it'd be better to make it a
policy that haskell library docs will have to have Depends: ghc6-doc
(<< $(ghc6-source-version)+), ghc6-doc (>= $(ghc6-source-version))
from now on. Should be doable easily enough with haskell-devscripts
and by using ${haskell:Depends} in -doc's Depends line. Any comments
on this?
I suspect that I may yet need to have a versioned conflict in ghc6-doc
on all haskell library -doc packages that didn't have a versioned
dependency on ghc6-doc and carry that until Squeeze's release. Argh.
I've fixed a bunch of bugs with this upload. ghc6-doc uses triggers
to run gen_contents_index now. This means that Haskell libraries
won't need to have postinst/postrm scripts to run it when they put
documentation in /usr/share/doc/ghc6-doc/libraries/.
I'll still want to see it to confirm it, but chances are that the
stage2 compiler is buildable on all architectures with 6.10.1. This
would mean that ghci, runghc and Template Haskell would work
everywhere. Win.
I'm not quite sure about what to do with haskell-utils. While there
isn't anything fundamentally wrong with it, I still don't like its way
of building haskell library packages. I know that I'll convert any
packages that I'm going to adopt, that use it, to haskell-devscripts
along the way. I'll be adopting Igloo's library packages along the
way, unless someone wants to call dibs.
As for the other thing that haskell-utils does, namely maintaining
/var/lib/haskell-utils/compilers (see haskell-utils(8))... I don't
know. AFAIK it's not used for anything, currently. Can anyone think
of a scenario where it could be useful? I don't expect to be
maintaining multiple versions of GHC in Debian. I suspect that if
there's a need for what haskell-utils does with registering compilers,
then it could be done with dpkg triggers, now.
We could stand to unify haskell-devscript's usage a bit. I'm hoping
that the version of mtl I packaged works as a good example of that;
the latest copy of the hlibrary.mk I used for it can be found at
http://people.debian.org/~kaol/repos/hlibrary/. I know some people
don't like CDBS. Debhelper v7 may offer another viable option. IMHO,
even telling people to call the individual dh_haskell_* scripts is
better than dh_haskell. Not all that Python programmers think of is
good.
I'm not sure how handling documentation like this plays along with
hugs. It may be enough if /usr/share/doc/$(whatever)-doc/html/ was a
symlink to the corresponding directory under
/usr/share/doc/ghc6-doc/libraries/.
A goal I'd like to push for, regarding haskell libraries:
binNMUability. Optimally, a new version of GHC could be handled with
binNMUs to all libraries that are still forward compatible.
haskell-devscripts already goes a long way towards this, with
${haskell:Depends}.
Lastly, sorry about the mess with ghc6_6.8.2dfsg1-1.
Attachment:
signature.asc
Description: Digital signature