Bug#659081: Taking binary from hackage or GHC?

2012-02-08 Thread 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).

 * 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
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part


Bug#659081: Taking binary from hackage or GHC?

2012-02-08 Thread Duncan Coutts
On 8 February 2012 10:24, Joachim Breitner nome...@debian.org wrote:
 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



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#659081: Taking binary from hackage or GHC?

2012-02-08 Thread Ian Lynagh
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




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org