ghc-7.6.2 breaks haddock interface...
Hi, I built GHC 7.6.2-rc1 for Debian. Unfortunately, we have this: Control files of package ghc-haddock: lines which differ (wdiff format) ----------------------------------------------------------------------- Depends: ghc (= [-7.6.1-3),-] {+7.6.1.20121207-1),+} libc6 (>= 2.11), libffi5 (>= 3.0.4), libgmp10 Installed-Size: [-32917-] {+33044+} Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+} Version: [-7.6.1-3-] {+7.6.1.20121207-1+} i.e. upstream has bumped the haddock interface number. I really was not expecting this from a minor release. @GHC devs: Is that intentional? I.e., is there really a change to the on-disk format of the .haddock files? Can we expect this to be stable until 7.6.2 final? In general, please only bump the interface number if really required, makes live much easier for us (and probably also for some of your other users). @Debian: If the answer is yes, what should we do? I think I have automated rebuilding everything (at least everything in Darcs) enough to make that not as painful as it used to be, but it would still take some time. On the other hand, it would break Haskell in experimental for some time (maybe a week, optimistically). But then, it is already partly broken. Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Hi Joachim, On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
I built GHC 7.6.2-rc1 for Debian.
Thanks for testing!
Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
i.e. upstream has bumped the haddock interface number. I really was not expecting this from a minor release.
@GHC devs: Is that intentional?
CCing the haddock dev list.
I.e., is there really a change to the on-disk format of the .haddock files? Can we expect this to be stable until 7.6.2 final?
In general, please only bump the interface number if really required, makes live much easier for us (and probably also for some of your other users).
@Debian: If the answer is yes, what should we do? I think I have automated rebuilding everything (at least everything in Darcs) enough to make that not as painful as it used to be, but it would still take some time. On the other hand, it would break Haskell in experimental for some time (maybe a week, optimistically). But then, it is already partly broken.
Won't you have to rebuild everything anyway, due to the GHC version number in the .hi files changing? Thanks Ian
Dear Ian, Am Mittwoch, den 12.12.2012, 00:52 +0000 schrieb Ian Lynagh:
Won't you have to rebuild everything anyway, due to the GHC version number in the .hi files changing?
good point; let me add a bit of information about the Debian infrastructure: There are two ways of rebuilding stuff. Regular uploads and binNMUs. Regular uploads require manual work: Adding a changelog entry to the source file, building it locally (which is required and means that the developer has to make sure he builds everything in the right order, and that he has to install previously built packages), signing the package and then uploading the new source package together with the built package. Tedious work. binNMUs can be scheduled programatically and cause the Debian autobuilder infrastructure to built the package again on the selected architectures (possibily all). The infrastructure is smart enough to figure out the build order itself and no further interaction is required. Nice. Unfortunately, the latter can only rebuild arch-dependent packages, which in the context of Debian packages means -dev and -prof. Architecture independent packages (here: -doc) cannot be built this way and thus can only be rebuilt by full sourceful uploads. The .hi files reside in the arch-dependent packages, while the .haddock files don’t. I know that you might think now: Well, then fix your infrastructure. A valid point. But I am not in the position to do so, hence my hope for only as many haddock interface number bumps as required. (The Debian side thinks things about Haskell like: Well, get your ABIs stable so that we can bugfix individual packages without breaking other packages...) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Hi Joachim, On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
there really a change to the on-disk format of the .haddock files?
Yes, the on-disk format changed, hence the interface version was bumped from 21 to 22. But Haddock can still read files with interface version 21 (see [1]). Cheers, Simon [1] https://github.com/ghc/haddock/blob/ghc-7.6/src/Haddock/InterfaceFile.hs#L81
Hi Simon, Am Mittwoch, den 12.12.2012, 12:15 +0100 schrieb Simon Hengel:
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
there really a change to the on-disk format of the .haddock files?
Yes, the on-disk format changed, hence the interface version was bumped from 21 to 22. But Haddock can still read files with interface version 21 (see [1]).
great! I was considering asking for backwards compatibility, but then tought it might be a bit too much. For now I’ll hardcode the information that haddock support interface version 21 in our package metadata, but this is error prone. Would you mind adding an option akin to $ haddock --interface-version that would print all versions (e.g. space separated)? $ haddock --compatible-interface-versions 21 22 Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
On Wed, Dec 12, 2012 at 12:30:10PM +0100, Joachim Breitner wrote:
Hi Simon,
Am Mittwoch, den 12.12.2012, 12:15 +0100 schrieb Simon Hengel:
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
there really a change to the on-disk format of the .haddock files?
Yes, the on-disk format changed, hence the interface version was bumped from 21 to 22. But Haddock can still read files with interface version 21 (see [1]).
great! I was considering asking for backwards compatibility, but then tought it might be a bit too much.
For now I’ll hardcode the information that haddock support interface version 21 in our package metadata, but this is error prone. Would you mind adding an option akin to $ haddock --interface-version that would print all versions (e.g. space separated)?
$ haddock --compatible-interface-versions 21 22
Should be easy. Can you open a ticket? (of course, patches are always welcome ;) Cheers, Simon
participants (3)
-
Ian Lynagh -
Joachim Breitner -
Simon Hengel