[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should jhc package be maintained by DHG?



Hi, Joachim.
# Sorry for my slow work about hoogle...

On Fri, Feb 1, 2013 at 7:35 PM, Joachim Breitner <nomeata@debian.org> wrote:
>> Now, I am trying to pack jhc <http://repetae.net/computer/jhc/> as
>> Debian package.
>>
>> Should jhc package be maintained by DHG?
>
> sure, why not.

Thank's a lot.

>> Q1. Should jhc's library package name has "libjhc-foo-{dev,doc}" on
>> Debian package name space?
>
> You say „jhc’s library package”, not “packages” – is there a single
> package containing all libraries supported by jhc? Or are there several?

Now, jhc include some haskell libraries in jhc's source code directory.
And my jhc Debian package includes them.

$ grep "\.hl" /var/lib/dpkg/info/jhc.list
/usr/share/jhc-0.8/containers-0.3.0.0.hl
/usr/share/jhc-0.8/safe-0.2.hl
/usr/share/jhc-0.8/haskell2010-0.8.1.hl
/usr/share/jhc-0.8/pretty-1.0.1.1.hl
/usr/share/jhc-0.8/QuickCheck-1.2.0.0.hl
/usr/share/jhc-0.8/flat-foreign-1.0.hl
/usr/share/jhc-0.8/transformers-0.2.1.0.hl
/usr/share/jhc-0.8/haskell98-1.0.hl
/usr/share/jhc-0.8/xhtml-3000.2.0.1.hl
/usr/share/jhc-0.8/haskell-extras-0.8.1.hl
/usr/share/jhc-0.8/jhc-1.0.hl
/usr/share/jhc-0.8/Diff-0.1.2.hl
/usr/share/jhc-0.8/filepath-1.2.0.0.hl
/usr/share/jhc-0.8/smallcheck-0.4.hl
/usr/share/jhc-0.8/applicative-1.0.hl
/usr/share/jhc-0.8/parsec-2.1.0.1.hl
/usr/share/jhc-0.8/deepseq-1.1.0.2.hl
/usr/share/jhc-0.8/HUnit-1.2.2.1.hl
/usr/share/jhc-0.8/jhc-prim-1.0.hl
/usr/share/jhc-0.8/html-1.0.1.2.hl

The hl files are Haskell libraries compile with jhc.
Today, jhc only supports above Haskell libraries.
But someone (include me) will build and pack the other Haskell
libraries for Debian System.
I think they should "libjhc-foo-{dev,doc}" name space.
Is it correct?

>> Q2. Should jhc use cabal to maintain the library pacage?
>
> Does Cabal support creating library with jhc? Does jhc have an
> equivalent to ghc-pkg, i.e. a package database? Does it work the same
> way?

No. Jhc doesn't have Cabal support and package database.
Jhc uses Haskell libraries with hl file path only.
Jhc needs own yaml format file to translate Haskell library to hl file.
Jhc cabal support will be available with some hack, but it's hard work
for me....

> Does jhc even support compiled libraries, or does it need the
> source (like hugs did)?

Yes. Jhc support compiled libraries as hl file.
It needs no source code to use from jhc.
Haskell library source code is only needed when jhc compiles it to hl file.

>> Q3. Should jhc library packages share the source packages with ghc's?
>
> If you are building from the same source, it should be in Debian only
> once, so yes.

Jhc can't compile latest Haskell packages on Hackage DB.
I tried to upgrade version of them, but all Haskell libraries included
with jhc source directory.
But it's not merged to upstream jhc.

> The same questions will come up for other compilers (fay, e.g.).
> Unfortunately, supporting another compiler to the same extend as GHC
> will be hard work – ~500 Haskell packages need to be touched, every
> version bump will have to work with all compilers, a package not
> building with one compiler will hold up the complete build. There is a
> reason why we eventually dropped Hugs support for the library packages.

I agree.
Then I think it's good idea that GHC's and jhc's library package name
space are isolated.

How about using "libjhc-foo-dev" as jhc's binary package name,
and "haskelljhc-foo" as jhc's source package name.
In future, jhc's source package name should be change into "haskell-foo",
when jhc can share source package with GHC.

Best regards,
--
Kiwamu Okabe


Reply to: