[Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13

[Jens Petersen <petersen redhat com>]

Yaakov Nemoy さんは書きました:
> 2008/8/28 Jens Petersen <petersen redhat com>:
>> Yaakov Nemoy さんは書きました:
>>> If we do this, then each 'library' package is going to have to support
>>> every single compiler we have.
>> No they don't have to but they can if they want. :)
> 
> It would be messy.
> 
>>> I would rather have one SRPM per library per compiler.
>> I thought we proposed "haskell-%pkg_name" exactly for this?
> 
> Nope, that's why it's %haskell_compiler-%pkg_name exactly for this.
> Otherwise, we can only support one compiler without a lot of weird
> tricks.

I quote from PackagingDrafts/Haskell...:

"If a library supports multiple Haskell compilers or interpreters, the
base name should instead be prefixed with haskell, e.g. haskell-X11."

So you want to withtract this? :)

> (Granted, we could just include multiple macros for multiple compilers
> in a single spec file, and then build and publish a single RPM for
> each library that supports multiple compilers.  I think this would
> lead to alot of bloat.  Alternatively, we could have a single spec
> file per library, and have it generate multiple subpackages, one for
> each compiler.  I would rather have one spec per compiler per
> library.)

Well that is what they do in the Emacs Lisp world for Emacs and XEmacs
and it works: it is a really pain having to maintain parallel packages
for different compiler.

Actually we could face this problem immediately if Rajesh submits
haskell-Cabal, since it should really be packaged for both ghc and hugs98.

> AFAIK, the run time you use to run Setup.hs is the runtime that the
> library is compiled against.  Namely, runhaskell that runs runghc
> would create a package for GHC.

I don't think it matters since it is only "scripting" and cabal is
supposed to be portable Haskell98 presumably.

Jens