Haskell Packaging Guidelines

Spec files in line with these templates are generated automatically by the cabal-rpm packaging tool which also adds dependencies listed in the package’s .cabal configuration file. Most packages should then build, though for some packages it may be necessary to specify some additional BuildRequires and/or Requires, and to check non-Haskell devel dependencies.

Standardizing the packaging helps to lower the maintenance burden across Fedora’s Haskell packages.

There are three types of Haskell Cabal packages: library (Lib), binary only (Bin), and binary with library (BinLib):

Haskell Bin packages should follow the usual Fedora Package Naming Guidelines for base package naming: i.e., follow the upstream name. Examples include projects like alex and cabal-install.

The names of Haskell Lib packages, packaged for ghc, are prefixed by "ghc-". For example the Haskell aeson library package is named ghc-aeson, and the Haskell X11 library package is named ghc-X11, etc.

Haskell BinLib packages should be named like a Bin package if the most important part they provide is an executable (eg hlint, ShellCheck, and pandoc), otherwise they should be named and packaged as a Lib package (eg ghc-hakyll (has a setup executable), ghc-vty (has demo executables)) if they are actually a library that includes an helper executable or demo or minor utility. In this case typically the executable should live in the devel subpackage (or maybe the library base package if it is used at runtime).

Note that having different Haskell source packages named "ghc-xyz" and "xyz" is not allowed since they would both correspond to the same upstream package named "xyz" on Hackage.

BinLib packages should subpackage their libraries with naming following Lib packages. For example the pandoc BinLib package has library subpackages

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, including package dependencies.

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 +

If needed Cabal flags for build options should be set by changing the package’s .cabal file: this can usually be done with the cabal-tweak-flag script to avoid having to carry and maintain patches for this.

For example cabal-tweak-flag systemlib True might enable a flag to use a system library dependency.

%cabal_configure_options can be set to pass other options to Cabal.

Modifying the .cabal file flags defaults allows packagers and tools like cabal-rpm to track actual package dependencies correctly.

The cabal-tweak-dep-ver script can used to change version bounds of dependencies in the package’s .cabal file: cabal-tweak-dep-ver deppkg oldbound newbound

eg: cabal-tweak-dep-ver base '< 4.16' '< 4.17'

Similarly cabal-tweak-drop-dep for dropping a redundant dependency (eg a compatibility dummy package).

eg: cabal-tweak-drop-dep mtl-compat

Spec file build dependencies are generated by the cabal-rpm packaging tool.

Binary RPM dependencies for Haskell libraries are automatically generated at build-time by the ghc-deps.sh script.

GHC uses static libraries for linking by default. Lib and BinLib packages should provide static, shared, and profiling libraries:

Since GHC assumes static versions of libraries are installed they need to be in the devel subpackage and it doesn’t make sense to subpackage them.

Executables in Bin and BinLib packages should be statically linked for portability.

Due to how GHC links shared libraries using --no-as-needed they generate a lot of rpmlint E: undefined-non-weak-symbol errors, this is unfortunately currently expected (see these upstream issues).

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:

They are used in the templates and explained in more detail below.

Executables are statically linked to Haskell libraries by default.

%ghc_bin_build is used to configure and build bin packages. It runs:

%ghc_bin_install is used to install bin packages. It runs:

Devel subpackages need to setup some Requires:

Lib packages need to use %setup -n:

Both Lib and BinLib have:

%ghc_lib_build is used to configure, build and generate documentation for Lib and BinLib packages. It runs:

%ghc_lib_install is used to install Lib and BinLib packages. It runs:

Debuginfo is currently disabled for Haskell packages, because ghc’s Dwarf output is not very useful. Stack backtraces can also be generated using profiling libraries.

GHC libraries are installed under %ghclibdir/%{pkg_name}-%{version}:

Library documentation lives under %ghclibdocdir/%{pkg_name}-%{version}.

Filelists for shared and devel library subpackages are generated through %ghc_lib_install using the macro %ghc_gen_filelists.

It generates the filelists ghc-%{pkg_name}.files, ghc-%{pkg_name}-devel.files, ghc-%{pkg_name}-prof.files, and ghc-%{pkg_name}-doc.files.

Packages compiling Haskell code without Cabal, i.e., directly with ghc or ghc --make, should use -O1 optimization, like Cabal does by default.