Hi,
Am Montag, den 19.01.2009, 15:24 +0200 schrieb Kari Pahula:
> I've just uploaded haddock 2.4.1-1, ghc6 6.10.1-1 and a new build of
> mtl library to experimental.
great!
> 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.
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?
> 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?
Packages generated with haskell-utils have this already:
$ grep-aptavail -F Depends 'ghc6-doc (<< ' -s Package
Package: libghc6-alut-doc
Package: libghc6-arrows-doc
Package: libghc6-cgi-doc
Package: libghc6-fgl-doc
Package: libghc6-glut-doc
Package: libghc6-haskell-src-doc
Package: libghc6-hgl-doc
Package: libghc6-html-doc
Package: libghc6-hunit-doc
Package: libghc6-mtl-doc
Package: libghc6-network-doc
Package: libghc6-openal-doc
Package: libghc6-opengl-doc
Package: libghc6-parallel-doc
Package: libghc6-parsec-doc
Package: libghc6-quickcheck-doc
Package: libghc6-stm-doc
Package: libghc6-stream-doc
Package: libghc6-terminfo-doc
Package: libghc6-time-doc
Package: libghc6-x11-doc
Package: libghc6-xhtml-doc
Package: libghc6-xmonad-contrib-doc
Package: libghc6-xmonad-doc
Package: libghc6-zlib-doc
> 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.
Unless my regex skills fail, there are only three such packages:
$ grep-aptavail -F Depends 'ghc6-doc' |grep-dctrl -v -F Depends 'ghc6-doc (<<' -s Package,Depends
Package: libghc6-diff-doc
Depends: ghc6-doc
Package: libghc6-irc-doc
Depends: ghc6-doc
Package: libghc6-utf8-string-doc
Depends: ghc6-doc
> 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/.
Great!
> 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.
Greater! (With the Debian-On-the-FreeRunner-hat on)
> I'll be adopting Igloo's library packages along the
> way, unless someone wants to call dibs.
As already said on IRC, I’ll take over X11 and hgl.
> 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 guess I’ll take this as an opportunity to dig deeper into cdbs, and to
keep the packages more consistent.
I see your libghc6-mtl-prof package does depend on any libghc6-mtl-dev,
but shouldn’t that be libghc6-mtl-dev (= ${binary:Version})?
> 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}.
Not only a new version of GHC, but also new versions of libraries. For
that, the Build-Dependencies of libraries have to be less strict than
currently stated in the Haskell Policy. In summary, I can find three
approaches to Build-Dependencies:
Using ==
--------
This is what[1] specifies:
„Furthermore, they must build-depend on the exact version of
the Haskell libraries they use in order to keep the packages
in sync across all arches.“
The advantage is just this: Packages, if they can be built, are built in
sync across all arches.
Disadvantages are:
* wanna-buid does not support AutoDepWait for ==, so packages will be
tried to early by the autobuilders and need manual re-trying from the
buildd-admins, which has caused them to hate Haskell already.
* You can not binNMU libraries because of newer other libraries.
* Backporting or self-compiling is harder than necessary
* The real dependencies are not expressed.
Using >=
--------
A variant of using ==.
Advantages:
* Thanks to working AutoDepWait, a package is only touched by buildds
when it can actually build.
* You can binNMU libraries.
Disadvantages:
* Backporting or self-compiling is harder than necessary (but better
than above)
* The real dependencies are not expressed.
Using the real dependencies
---------------------------
A third way is to only specify the dependencies as far as the Cabal file
indicates them (or there are other hard reasons for them), if at all.
Advantages:
* Backporting, self-compiling much easier
* Real dependencies are expressed
* binNMUs are possible
Disadvantages:
* A package could be auto-build too early, against an old version of ad
dependency, and a binNMU will be required to get them in sync. This can
be sometimes avoided by using the delayed queue.
Without AutoDepWait-support for ==, this is not a viable solution in my
opinion. I’m not sure if >= or real dependencies are better. I find the
third option cleaner, but if packages need to be re-built too often,
this might be troublesome.
There is also the issue of binary dependencies. Currently, the policy
specifies strict dependencies there as well. But this means that a
compatible change to haskell-X11, for example, will require re-builds of
haskell-hgl, xmonad, and xmonad-contrib.
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
which would stay equal unless the cabal version changes or the ABI
changes. Depending packages would then depend on this virtual package
and would not need new builds if the packages changes in a compatible
way.
This can be implemented gradually, as packages not providing such a
virtual package name will be depended on strictly, as usual.
So far, nobody has pointed out a serious flaw with this, but it might
just be because nobody has cared yet to have a look :-)
> Lastly, sorry about the mess with ghc6_6.8.2dfsg1-1.
Thanks for taking care of the mess, and thanks for the new momentum for
Haskell in Debian!
Greetings,
Joachim
[1] http://urchin.earth.li/~ian/haskell-policy/haskell-policy.html/ch-libraries.html#s-library_impl_deps
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil