I have yet to sift through FTBFS issues. Don't bother to file bugs,
they won't go anywhere and I'm certain to not upload ghc6 to unstable
before I see it build on every arch on experimental buildds' logs with
my own eyes. I've been mostly looking at haddock usage, since -1.
Thanks for your comments so far.
On Mon, Jan 19, 2009 at 05:24:02PM +0100, Joachim Breitner wrote:
> > 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
> Did I understood this correct: 2) will have ghc6-doc disabled (or
> build-failure-is-not-critical), and 4) will be the proper upload? Or is
> the the same source, and 4) could be done with a binNMU?
No, I didn't understand it correctly. Something I overlooked: ghc's
build system doesn't use haddock from /usr/bin/ even if it's there.
Instead, it includes a copy of haddock along with the rest of the
sources and builds it along the way and uses that version to build the
HTML docs in ghc6-doc. ghc6's build dep on haddock doesn't affect
anything, currently.
I would much prefer to use the same version of haddock for all Haskell
API docs, to have a single place to patch if (when) something needs to
be fixed in haddock. I patched ghc6's build system for -2 to not
build its own haddock and always use /usr/bin/haddock. Also, I
disabled building haddock docs for now. I'd much prefer to weed out
all the build failures first.
So, the order of things when this goes to unstable:
1) build ghc6, without haddock docs
2) build haddock (build dep >= ghc 6.10.1)
3) build ghc6 again, with haddock docs (build dep >= haddock 2.4.1)
> > 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))
Looks like there's no need to be quite that stringent about it.
.haddock files from 0.8.4 aren't forward compatible with 2.4.1, but
the latter can detect the former from their magic numbers.
gen_contents_index will just generate some warning messages and
nothing else will happen if an older .haddock file got left around.
What matters is that the version of ghc haddock is built with matches
with the version that a package is building itself with. But this is
easy to ensure, already.
Speaking of .haddock files, I'm a bit uncomfortable with how they're
placed, currently. gen_contents_index detects and processes any
.haddock files that are in directories under
/usr/share/doc/ghc6-doc/libraries/. But I don't think that using
anything from under /usr/share/doc/ as an input for an automated tool
is a good principle. Though there's no problem with using it for
their output, as far as I see. How about designating
/usr/share/ghc6-doc/haddock/ for .haddock files?
Regarding the placement of the docs itself, I'm fine with either
/usr/share/doc/ghc6-doc/libraries/$(CABALNAME)/ or in their own
/usr/share/doc/ subdir, with the former as a symlink. We'll just need
to be mindful of that Cabal names form a namespace of their own.
> I see your libghc6-mtl-prof package does depend on any libghc6-mtl-dev,
> but shouldn???t that be libghc6-mtl-dev (= ${binary:Version})?
Yes.
I'll still have to think a bit more about what hlibrary.mk does before
endorsing it fully. Like having it build twice when there's a -prof
package looks questionable.
> > A goal I'd like to push for, regarding haskell libraries:
I'll still have to read and think about this fully. But I can name
one concern already...
> I already introduced the idea of using a hash of the interfaces hashes
> in the .hi files in the package to automatically, with
> haskell-devscripts, provide a
> > Provides: libghc6-mtl-dev-1.1.0.2-ABCDEF012345679
I don't think that polluting dpkg's namespace like that is a good
idea. Treat it as a scarce resource. Those names are bound to left
lying around for a time and soon there's going to be thousands of
those. I think aptitude is slow enough as it is.
This would inevitably raise things that don't concern people not using
Haskell to their eyes. I don't like that.
Not to mention that this usage of Provides is contrary to what Policy
3.6 describes. It's meant for cases when there are several real
packages providing a similar functionality. Your proposal gets this
backwards.
Attachment:
signature.asc
Description: Digital signature