PackagingDrafts/Haskell
From FedoraProject
Contents |
Haskell Packaging Guidelines
This page documents the guidelines and conventions for packaging Haskell projects in Fedora.
GHC (Glasgow Haskell Compiler) is the current mainstream Haskell compiler. Most Haskell packages are released on Hackage and use the Cabal package system. So currently these guidelines focus on packaging for GHC using Cabal.
Spec file templates and cabal2spec
There are three types of Haskell Cabal packages: binary only (Bin), library only (Lib), and binary and library (BinLib).
cabal2spec can create .spec files based on these templates:
directly from a Cabal package tarball or .cabal file. Using these standard packaging templates lowers the maintenance burden considerably across Fedora's Haskell packages. With a little review and editing the .spec files should then build for most Cabal packages: for example it may be necessary to specify BuildRequires for build dependencies and Requires for any runtime or non-Haskell devel dependencies. Please report any problems in bugzilla against the cabal2spec component.
Additionally cabal2spec provides a cabal2spec-diff command which allows one to quickly see
how a .spec files deviates from the generated cabal2spec .spec file.
Naming
Haskell Bin and BinLib packages should follow the usual Fedora Package Naming Guidelines for base package naming: ie follow the upstream name. Examples include projects like darcs and xmonad. BinLib packages should subpackage their libraries with naming following Lib packages.
For example the xmonad BinLib package has library subpackages
-
ghc-xmonadfor the shared library, and -
ghc-xmonad-develfor devel files and the static library.
The names of Haskell Lib packages built for ghc are prefixed by "ghc-". For example the zlib library package is named ghc-zlib, and the QuickCheck library is named ghc-QuickCheck.
If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with haskell, e.g. haskell-X11. Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. ghc-X11, hugs98-X11, etc).
Package naming preserves case to follow the upstream naming conventions as closely as possible.
Headers
The macro pkg_name is used to carry the name of the upstream library package (i.e. without the Fedora "ghc-" prefix).
It should be defined at the top of Lib and BinLib packages:
%global pkg_name <package>
The macros common_summary and common_description are used as the basis
for Summary and Description respectively for the Lib and BinLib base and subpackages.
It is recommended to define them otherwise simple generic text based on pkg_name will be used for the subpackages.
GHC uses static libraries by default, but now also supports shared libraries on some platforms. Lib and BinLib packages should provide static, shared, and profiling libraries:
- the shared library lives in the base library package, and
- the static and profiling library and header files in the -devel subpackage.
Because GHC still assumes static versions of libraries are installed they need to be in the devel subpackage and it doesn't make sense to subpackage them yet.
Executables in Bin and BinLib packages should be dynamically linked to shared libraries.
Note that executables in BinLib packages are currently staticly linked against the library in their own package, but will be dynamically linked against other dependent libraries.
Some particular packages may do user compilation during runtime in which case they will need Requires as well as BuildRequires for their dependencies: examples include xmonad and yi which require their devel package to be present to allow users to relink their configuration or customization.
RPM Macros
The templates all have buildrequires for ghc-rpm-macros, which provides macros.ghc to assist with packaging Haskell Cabal packages.
The main commonly used macros are:
- %ghc_bin_build, %ghc_lib_build
- %ghc_bin_install, %ghc_lib_install
- %ghc_devel_package, %ghc_devel_description
- %ghc_package, %ghc_description
- %ghc_devel_post_postun
- %ghc_files
They are used in the templates and explained in more detail below.
Generally the macros should just work and do the right thing, but if necessary a macro can be replaced by its expansion and then tweaked in order to get a package to build for Fedora.
Bin packages
Bin package executables are dynamically linked to shared Haskell libraries when available, but this can be overridden if necessary by defining the ghc_without_dynamic macro.
-
%ghc_bin_buildis used to configure and build bin packages. It runs:-
%global debug_package %{nil}: debuginfo is disabled since ghc's output is not in DWARF format. -
%cabal_configure: configure the package for building and dynamic linking. -
%cabal build: builds the package.
-
-
%ghc_bin_installis used to install bin packages. It runs:-
%cabal_install: installs the package. -
%ghc_strip_dynlinked: strips the dynamically linked binary.
-
Lib and BinLib packages
BinLib package executables are dynamically linked to other shared Haskell libraries when available, but this can be overridden if necessary by defining the ghc_without_dynamic macro.
-
%ghc_lib_buildis used to configure, build and generate documentation for Lib and BinLib packages. It runs:-
%global debug_package %{nil}: debuginfo is disabled since ghc's output is not in DWARF format. -
%cabal_configure --ghc -p: configures the package for building with ghc and profiling. Libraries should build profiling versions of their static libraries. -
%cabal build: builds the package. -
%cabal haddock: generates HTML library documentation from the source code.- If necessary (if e.g. documentation is failing to build for some reason) this can be skipped by defining
without_haddock. - Additionally links to colored html sourcecode are also generated with
hscolour, which can be disabled by definingwithout_hscolour.
- If necessary (if e.g. documentation is failing to build for some reason) this can be skipped by defining
-
-
%ghc_lib_installis used to install Lib and BinLib packages. It runs:-
%cabal_install: installs the package without registering it in ghc-pkg. -
%cabal_pkg_conf: creates ghc-pkg .conf metadata file for package installation time -
%ghc_gen_filelists: generates rpm filelists. -
%ghc_strip_dynlinked: strips dynamically linked objects.
-
-
%ghc_devel_package: Boilerplate to define devel subpackages. -
%ghc_devel_description: Boilerplate for devel subpackage description.
-
%ghc_package: BinLib boilerplate to define base library subpackage. -
%ghc_description: BinLib boilerplate for base library subpackage description.
-
%ghc_devel_post_postun: post and postun boilerplate for devel subpackage.- The install scripts run
%ghc_pkg_recacheto refresh the ghc package cache database with .conf file data.
- The install scripts run
-
%ghc_files: Helper macro for %files lists for base library and devel subpackages (see below).
Directories
GHC libraries are installed under %ghcpkgdir/%{pkg_name}-%{version}:
Library documentation lives under %ghclibdocdir/%{pkg_name}-%{version}.
File lists
Filelists for shared and devel library subpackages are generated using the macro %ghc_gen_filelists.
It generates the filelists: ghc-%{pkg_name}.files and ghc-%{pkg_name}-devel.files.
The files sections are boilerplate generated by the %ghc_files.
If you need to add additional %doc files to the base library package they can pass them as arguments to %ghc_files.
Additionally files to the devel subpackage can be appended below %ghc_files.
For example:
%ghc_files COPYING %doc README
adds a license files to the base library package and a README file to the devel subpackage.
