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(a)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