Taking binary from hackage or GHC?

Dear interested parties :-), GHC 7.4.1 started to ship and expose the binary library, version 0.5.0.3. On hackage is binary-0.5.1.0. In Debian, we try to provide one version of each library, so we have to decide: * Use the version provided by GHC and drop the independent binary package (as we have done with random, for example). * Do not expose binary in GHC and continue using the version from hackage. @Upstream: Do you think binary on hackage will diverge much from the one in GHC and would you expect your users to want the new versions before they are shipped with GHC? And do you expect breakage in any components (e.g. haddock) if everything but GHC uses a newer binary package? 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

On 8 February 2012 10:24, Joachim Breitner
Dear interested parties :-),
GHC 7.4.1 started to ship and expose the binary library, version 0.5.0.3. On hackage is binary-0.5.1.0.
It was firmly my opinion that shipping and exposing binary in GHC was and is a mistake. Previously it was given a different name to try to discourage people using it, but apparently that didn't work. The authors of binary (myself included) don't want to ship it yet as part of the Haskell Platform because the API isn't right yet (ongoing work), and shipping it with GHC effectively makes it part of the platform.
In Debian, we try to provide one version of each library, so we have to decide:
Yes, you're not put in an easy situation. Nor will we be when we come to packaging the next HP release.
* Use the version provided by GHC and drop the independent binary package (as we have done with random, for example).
* Do not expose binary in GHC and continue using the version from hackage.
I'm not sure I have the whole answer, you'll also need a response from Ian. Eventually we will want to propose binary for the HP, but GHC may well still want to depend on binary and ship it. So it might end up as one of those HP libs that is shipped with GHC in the long term.
@Upstream: Do you think binary on hackage will diverge much from the one in GHC and would you expect your users to want the new versions before they are shipped with GHC?
No, it should not diverge much, GHC picks up the latest code from the upstream version occasionally.
And do you expect breakage in any components (e.g. haddock) if everything but GHC uses a newer binary package?
At some point, we will have a major version change and that will break the API and the binary format (we might even split the package in two). If they use similar versions but not the same, then probably the only thing to break would be haddock, since I'm guessing that it makes use of binary instances provided by the GHC package. But of course haddock is also shipped with GHC. Duncan

On Wed, Feb 08, 2012 at 11:24:00AM +0100, Joachim Breitner wrote:
GHC 7.4.1 started to ship and expose the binary library, version 0.5.0.3. On hackage is binary-0.5.1.0.
Actually, 7.4.1 comes with 0.5.1.0. The release notes have the wrong version number, unfortunately.
* Use the version provided by GHC and drop the independent binary package (as we have done with random, for example).
I would recommend this option. Thanks Ian

Hi, Am Mittwoch, den 08.02.2012, 11:24 +0100 schrieb Joachim Breitner:
Dear interested parties :-),
GHC 7.4.1 started to ship and expose the binary library, version 0.5.0.3. On hackage is binary-0.5.1.0. In Debian, we try to provide one version of each library, so we have to decide:
* Use the version provided by GHC and drop the independent binary package (as we have done with random, for example).
That should not be random (which went the other way, from GHC to a package of its own), but deepseq. It seems that upstream recommends to take this path, so I’ll request removal of the package soon. @DHG: This means that the version constraint on the libghc-binary-* dependencies need to be removed, as ghc provides libghc-binary-dev, but such provides never carry a version number in Debian. The build dependency itself can stay; it doesn't hurt and will prevent failed builds if some future GHC packages stops exposing binary. 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
participants (3)
-
Duncan Coutts
-
Ian Lynagh
-
Joachim Breitner