[Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13
Rajesh Krishnan
fedora at krishnan.cc
Thu Aug 28 22:20:35 UTC 2008
Yaakov,
For Hackage packages that contain only libraries, or a single executable, the
package building specification is clear (name the RPM for library only
package xyz as ghc-xyz, and name the RPM for a single executable package xyz
as just xyz without the ghc prefix).
But the part of the specification is not clear to me is:
What would be the RPM name for a Hackage package xyz that contains multiple
libraries and multiple executables? Is it OK to create a single RPM called
xyz in for such a package, or do they necessarily need to be split up into
multiple package fragments? Please explain if you could. Note that the
number of such fragmented RPMs would multiply fast (creation of perhaps -prof
and -doc etc. if applicable for each subpackage) .
Thanks in advance.
-Rajesh
On 2008-08-28-Thu 11:28:08 am Yaakov Nemoy wrote:
> On Thu, Aug 28, 2008 at 5:50 AM, Rajesh Krishnan <fedora at krishnan.cc> wrote:
> > Yaakov / Jens,
> >
> > Have we finally decided if what style of macros we wish to move forward
> > with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file
> > and liked the syntax, and created this sample package for the latest
> > version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8
> > and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot
> > resolution issues at the moment, and may not build on rawhide). Here are
> > the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3):
>
> cabal_* is a no go. It makes it *much* harder to support multiple
> compilers in the future. Remember these rules.
>
> All libraries theoretically need to have a seperate spec file (thus
> seperate package in CVS) for each compiler we ship. Thus:
> ghc-foo
> hugs98-foo
> barhc-foo
>
> For library foo in hackage.
>
> All packages that also ship with executables should be compiled with
> GHC (or give a good justification for using another compiler), thus:
> xmonad
> darcs
> haddock
>
> For xmonad, darcs, and haddock.
>
> Packages that do code generation, and ship both libraries and
> executables should also use GHC, but the library component should be
> named after GHC. Note that the library component is just a subpackage
> of the executable. Thus:
> xmonad
>
> For xmonad.
>
> > RPM(x86_64):
> > http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-
> >1.fc9.x86_64.rpm
> >
> > RPM(i386):
> > http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.
> >fc9.i386.rpm
> >
> > SPEC:
> > http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
> >
> > SRPM:
> > http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.
> >src.rpm
> >
> > macros.haskell:
> > http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell
> > (This is the modified file with cabal_* style macros as proposed by Jens.
> > Note that we need to place macros.haskell under /etc/rpm to successfully
> > build with the above .spec).
> >
> >
> > YAAKOV: Note that the macros.haskell file needs another variable
> > called %{internal_name} which needs to get defined in the spec for
> > Hackage that start with a capital letter (like the Cabal example
> > mentioned here). Otherwise it IMHO it is not possible keep the resulting
> > rpm name (ghc-cabal) in all lowercase letters as per the Haskell package
> > building specification.
>
> Uh, that part changed. We are now going with upstream names. This
> was to reduce complexity, since Upstream uses a consistent naming
> scheme.
>
> > If we have decided stay with the original macros.ghc style macros
> > (ghc_*) then I can update the package and resubmit with the modified
> > macros.ghc file. I am not biased towards either macros.ghc or
> > macros.haskell, and either one of them is fine with me (will need to
> > tweak them a bit of course).
> >
> > And also, could somebody help me with getting some file-hosting space on
> > FedoraPeople or Fedoraproject sites? That would help me upload the
> > packages and spec related files for public sharing.
>
> You should have some already with your FAS account.
>
>
> -Yaakov
More information about the Fedora-haskell-list
mailing list