[Fedora-haskell-list] [Bug 460304] Add macros to GHC for packaging cabal packages for GHC
bugzilla at redhat.com
bugzilla at redhat.com
Fri Sep 5 13:32:04 UTC 2008
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #19 from Rajesh Krishnan <fedora at krishnan.cc> 2008-09-05 09:32:03 EDT ---
Here is another problematic Hackage cabal package:
Crypto-4.1.0:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto
SRPM:
http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-crypto-4.1.0-1.fc9.src.rpm
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-crypto.spec
Macros: http://krishnan.cc/devel/repository/fedora/MISC/macros.ghc
(tested on F9 + GHC-6.8.3 installed, on x86_64).
The problems with this package are:
1. The package has mixed case package name (name starts with a capital
letter).
2. The package contains a number of executables (besides a library), but all
of those are test executables (not normally executed by end-users).
The way I solved these issues are are follows:
1. Mixed case is already taken care of the updated macros.ghc script I have
attached.
2. Because the package contains executables, the default package name as per
the Fedora Haskell Specification would be crypto-*.rpm and not
ghc-crypto-*.rpm.
The following are noteworthy for this package:
1. The library package are named ghc-crypto-<ver>.fc9.<arch>.rpm as per the
specification because they contain the library and associated library
documentation.
2. The profile packages are named ghc-crypto-prof-<ver>.fc9.<arch>.rpm as per
the spec.
3. I have an additional devel package called
ghc-crypto-devel-<ver>.fc9.<arch>.rpm that contains all the test executables:
$ rpm -ql ghc-crypto-devel
/usr/bin/HMACTest
/usr/bin/QuickTest
/usr/bin/RSATest
/usr/bin/SHA1Test
/usr/bin/SymmetricTest
for this case I am violating the current cabal package specification (which are
not set in stone I hope) for some (IMHO) good reasons
1. The test executables are not normally required by end-users.
2. The test executables are not normally required by even developers who
require compile their code against the library (contained in the main rpm) and
would probably never need these executables either.
3. These test executables don't seem to fit into the -prof package either.
4. I thought of dumping these test executables under the libexec folder like
(/usr/libexec/ghc-crypto) but for some reason didn't feel that was appropriate.
5. So the only option was to spin-off another package that is named
appropriately (-devel).
6. I didn't feel like giving the too-important sounding name "crypto-*.rpm) of
a package that contains just a handful of (mostly unnecessarily) test
executables. Hence I have named this ghc-crypto-devel-*.rpm (and not
crypto-*.rpm or crypto-devel-*.rpm) in order to emphasize its affinity to the
actual rpm and source (ghc-crypto*.rpm).
Please review the package and let me know if we could do this differently or in
any other way.
YAAKOV/JENS:
If you (mostly) agree with the above logic, then we might need to update the
Fedora Haskell Packaging specification as follows:
1. For packages that contain executables that are only related to testing of
the package (not something that end users would usually need) the RPM for such
a package should be named as ghc-<PACKAGE>.*.rpm and not simply
<PACKAGE>.*.rpm, assuming its cabal file contains a library section.
2. For packages that contain executables that are related to testing only (and
other executables that may not normally be reuqired by end-users), the .SPEC
for such an RPM may define a -devel section containing only those test
executables.
3. For other packages that contain end-user oriented executables and/or
libraries, the general rules defined in the Fedora Haskell Packaging
Specification would apply as usual.
Feedback is welcome.
-Rajesh Krishnan
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Fedora-haskell-list
mailing list