From Fedora Project Wiki

(%define => %global)
(Deprecate this page.)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{OldGuidelinePage|Haskell}}
= Haskell Packaging Guidelines =
= Haskell Packaging Guidelines =
This page documents the guidelines and conventions for packaging [[Haskell]] projects in Fedora.


This documents the guidelines and conventions for packaging Haskell projects in Fedora.
[http://haskell.org/ghc GHC] (Glasgow Haskell Compiler) is the current mainstream Haskell compiler.
Most Haskell packages are released on [http://hackage.haskell.org Hackage] and use the [http://www.haskell.org/cabal/ Cabal] package system.  So the current guidelines mostly focus on packaging for GHC using Cabal.


== Spec file templates ==
Spec files in line with these templates are generated automatically by the [https://apps.fedoraproject.org/packages/cabal-rpm cabal-rpm] packaging tool
which also adds dependencies listed in the package's <code>.cabal</code> 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.


== What is Haskell? ==
There are three types of Haskell Cabal packages: library only (Lib), binary only (Bin), and binary and library (BinLib):


(from http://haskell.org/)
=== Library Only ===


Haskell is an advanced purely functional programming language. The product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software. With strong support for integration with other languages, built-in concurrency, debuggers, profilers, rich libraries and an active community, Haskell makes it easier to produce flexible, maintainable high-quality software.
<pre>
%global pkg_name @PACKAGE@
 
Name:          ghc-%{pkg_name}
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@
 
License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{pkg_name}
Source0:        http://hackage.haskell.org/packages/archive/%{pkg_name}/%{version}/%{pkg_name}-%{version}.tar.gz
 
BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros
 
%description
@DESCRIPTION@
 
%package devel
Summary:        Haskell %{pkg_name} library development files
Requires:      ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:      %{name} = %{version}-%{release}
 
%description devel
This package provides the Haskell %{pkg_name} library development files.
 
 
%prep
%setup -q -n %{pkg_name}-%{version}
 
 
%build
%ghc_lib_build
 
 
%install
%ghc_lib_install


GHC, or the Glasgow Haskell Compiler, is the most popular and widely used Haskell compiler.  It complies with Haskell 98, the latest official language specification, and also includes numerous experimental language ideas.  It represents a good picture of what the future of Haskell will look like, so it is a good choice for development.  Many Haskell programs work better or only with GHC.  So currently these guidelines mainly focus on packaging for GHC.  At some later stage if the need arises they may be extended to cover other implementation in more detail.


== Base package naming ==
%post devel
%ghc_pkg_recache


=== Libraries ===
Haskell library packages should be prefixed with the compiler or interpreter they are intended for.  Package names should follow the upstream naming and preserve case.  For example,  the <code>bzlib</code> library from [http://hackage.haskell.org/ Hackage] packaged for GHC would be named <code>ghc-bzlib</code> in Fedora, and the <code>QuickCheck</code> library would be named <code>ghc-QuickCheck</code>.


If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with <code>haskell</code>, e.g. <code>haskell-X11</code>.  Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. <code>ghc-X11</code>, <code>hug98-X11</code>, etc.
%postun devel
%ghc_pkg_recache


''Rationale: The Fedora Project tries to follow upstream as closely as possible.  Upstream maintains very consistent naming schemes, and mixed case names are tracked very well.''


=== Programs ===
%files -f %{name}.files
For packages of Haskell programs the usual Fedora Package Naming Guidelines must be followed: ie in they should follow the upstream name. Examples include projects like <code>darcs</code>, <code>haddock</code>, and <code>xmonad</code>.  If the package also generates libraries, then the libraries SHOULD be subpackaged as a Haskell library package named after the compiler or interpreter as above.
%license LICENSE


''Rationale: Binaries are not dependant on the compiler they were compiled with anymore than a C program is dependant on whether it's been compiled with gcc or icc.''


== Description ==
%files devel -f %{name}-devel.files
When packaging things out of [http://hackage.haskell.org Hackage]  or other sources, you may find that the description is incomplete or improperly labeled.  Please double check all parts of the package description so that it meets Fedora's standards for writing quality.


== Build and Install ==


<code>%build</code> and <code>%install</code> can be done through a series of macros that ensure correctness.
%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm
</pre>


=== Binary Only ===
<pre>
<pre>
Name:          @PACKAGE@
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@
License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{name}
Source0:        http://hackage.haskell.org/packages/archive/%{name}/%{version}/%{name}-%{version}.tar.gz
BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros
%description
@DESCRIPTION@
%prep
%setup -q
%build
%build
%cabal_configure
%ghc_bin_build
%cabal_build
 
%cabal_haddock
 
%install
%ghc_bin_install
 
 
%files
%license LICENSE
%{_bindir}/%{name}
 
 
%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm
</pre>
</pre>


''Note: Please include profiling libraries where possible or include a justification for not doing so.''
=== Library and Binary ===
 
<pre>
%global pkg_name @PACKAGE@
 
Name:           %{pkg_name}
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@


%cabal_build will build a package without installing it
License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{name}
Source0:        http://hackage.haskell.org/packages/archive/%{name}/%{version}/%{name}-%{version}.tar.gz
 
BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros
 
%description
@DESCRIPTION@
 
 
%package -n ghc-%{name}
Summary:        Haskell %{name} library
 
%description -n ghc-%{name}
This package contains the Haskell %{name} library.
 
 
%package -n ghc-%{name}-devel
Summary:        Haskell %{name} library development files
Requires:      ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:      ghc-%{name} = %{version}-%{release}
 
%description -n ghc-%{name}-devel
This package provides the Haskell %{pkg_name} library development files.
 
 
%prep
%setup -q
 
 
%build
%ghc_lib_build


%cabal_haddock builds haddock files


<pre>
%install
%install
rm -rf ${RPM_BUILD_ROOT}
%ghc_lib_install
%cabal_install
 
 
%post -n ghc-%{name}-devel
%ghc_pkg_recache
 
 
%postun -n ghc-%{name}-devel
%ghc_pkg_recache
 
 
%files
%license LICENSE
%{_bindir}/%{name}
 
 
%files -n ghc-%{name} -f ghc-%{name}.files
%license LICENSE
 
 
%files -n ghc-%{name}-devel -f ghc-%{name}-devel.files
 
 
%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm
</pre>
</pre>


%cabal_install will install the package without including the registration scripts for ghc's library management.  For libraries, see below how to achieve this.
== Package 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 <code>darcs</code> and <code>xmonad</code>.
However there may be cases where a Haskell BinLib package is really a Lib package with a minor or unimportant executable: in this case it is better to treat the package a Lib package, optionally with a executable subpackage if appropriate.
 
The names of Haskell Lib packages, packaged for <code>ghc</code>, are prefixed by "ghc-".  For example the Haskell X11 library package is named <code>ghc-X11</code>, and the Haskell mmap library package is named <code>ghc-mmap</code>, etc.
 
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 <code>xmonad</code> BinLib package has library subpackages
* <code>ghc-xmonad</code> for the shared library, and
* <code>ghc-xmonad-devel</code> for devel files and the static library.


== Packaging libraries ==
If a library is packaged for more than one Haskell compiler or interpreter, the base name should instead be prefixed with <code>haskell</code>, e.g. <code>haskell-X11</code>.  Such a package would then have subpackages for each compiler and/or interpreter it is built for (e.g. <code>ghc-X11</code>, <code>hugs98-X11</code>, etc).
GHC libraries should be installed under libdir/ghc as done by Cabal.


<pre>
Package naming preserves case to follow the upstream naming conventions as closely as possible.
%global pkg_libdir %{_libdir}/ghc-%{ghc_version}/%{pkg_name}-%{version}
 
</pre>
== Headers ==
 
The macro <code>pkg_name</code> 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>
 
== Cabal Flags ==
Cabal flags for build options should be set by changing the package's <code>.cabal</code> file: this can be done with the <code>cabal-tweak-flag</code> script to avoid having to carry and maintain patches for this.
<code>%cabal_configure_options</code> can be set to pass other options to Cabal.
 
Modifying the <code>.cabal</code> file flags defaults allows packagers and tools like <code>cabal-rpm</code> to track actual package dependencies correctly.
 
== Dependency Generation ==
Spec file build dependencies are generated by the <code>cabal-rpm</code> packaging tool.


=== File lists ===
RPM dependencies for Haskell libraries are automatically generated at build-time by the <code>ghc-deps.sh</code> script.
You can generate filelists using the following macro, rather than doing it by hand:


<pre>
The <code>cabal-tweak-dep-ver</code> script can be used to bump versions of dependencies in the package .cabal file.
%ghc_gen_filelists %{name}
</pre>


This macro takes one parameter, which is just a name to be used for the file lists.  This same parameter must be used later in the files section.
== Shared and static library linking ==
GHC uses static libraries by default, but supports shared libraries on some architectures: currently i686 and x86_64.  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.


The files section would then look something like this:
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.


<pre>
Executables in Bin and BinLib packages should be dynamically linked to shared libraries.
%files -f %{name}.files
%defattr(-,root,root,-)
%doc dist/doc/html
%doc LICENSE TODO README


Note that executables in most BinLib packages are currently staticly linked against the library in their own package (unless the .cabal file explicitly lists it as a dependency), but dynamically linked against other dependent libraries. BinLib executables that do link dynamically against their own library should use <code>%ghc_fix_dynamic_rpath</code> to fix its RPATH.


%files -n %{name}-prof -f %{name}-prof.files
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.
%defattr(-,root,root,-)
%doc LICENSE
</pre>


=== Install scripts ===
== RPM Macros ==
Libraries must be registered with the installed GHC.
The templates all have buildrequires for ghc-rpm-macros, which provides [http://pkgs.fedoraproject.org/cgit/ghc-rpm-macros.git/tree/ghc-rpm-macros.ghc macros.ghc] to assist with packaging Haskell Cabal packages.


To generate registration scripts that can be embedded in the package, include the following in %build, and include the following install script macros.
<pre>
<pre>
%ghc_gen_scripts
BuildRequires:  ghc-rpm-macros
</pre>
</pre>


To separate the copying phase from the registration phase of installation, include the following in %install
The main commonly used macros are:
<pre>
%ghc_install_scripts
</pre>


To register packages at install time, make sure to include the following bits:
* %ghc_bin_build
<pre>
* %ghc_lib_build
%pre -n ghc-%{pkg_name}
* %ghc_bin_install
%ghc_preinst_script
* %ghc_lib_install


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


%post -n ghc-%{pkg_name}
== Bin packages ==
%ghc_postinst_script


Bin package executables should be dynamically linked to shared Haskell libraries when available, but this can be overridden if necessary by defining the <code>ghc_without_dynamic</code> macro.


%preun -n ghc-%{pkg_name}
<pre>
%ghc_preun_script
%build
%ghc_bin_build




%postun -n ghc-%{pkg_name}
%install
%ghc_postun_script
%ghc_bin_install
</pre>
</pre>


== Packaging programs ==
<code>%ghc_bin_build</code> is used to configure and build bin packages. It runs:
Programs are packaged in their simple name, eg <code>xmonad</code> would remain <code>xmonad</code>.  Any libraries should go into a separate subpackage: eg the spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad. xmonad would require ghc-xmonad, but not visa versa.  ghc-xmonad would contain a line in its description explaining that these are the libraries necessary for xmonad to run.
* <code>%global debug_package %{nil}</code>: debuginfo is disabled since ghc's output is not in GDB format.
* <code>%cabal_configure</code>: configure the package for building and dynamic linking.
* <code>%cabal build</code>: builds the package.


Binary packages should be compiled with GHC when possible.  Some Haskell packages might require some compiler extension not provided in GHC. Alternate compilers may be used so long as they are packaged for Fedora. Please make it clear what feature is needed when submitting that package for review, and leave an appropriate comment in the spec file.
<code>%ghc_bin_install</code> is used to install bin packages.  It runs:
* <code>%cabal_install</code>: installs the package.
* <code>%ghc_strip_dynlinked</code>: strips the dynamically linked binary.


If a compiler is not available in Fedora, please submit it for package review as well.  We can block your review request on the compiler, and if they pass review, they can be accepted simultaneously.  Please note that your compiler must follow Fedora's guidelines for packaging and package submission.
== Lib and BinLib packages ==


''Rationale: Binaries are recognized on their name alone.  Furthermore, they do not require a compiler to run.  Therefore the name provided should simply be the upstream name.  GHC is the best supported compiler in Fedora currently.  Therefore, if something goes wrong, we have a larger skill base to ask for help.''
BinLib package executables should be dynamically linked to other shared Haskell libraries when available, but this can be overridden if necessary by defining the <code>ghc_without_dynamic</code> macro.


== Documentation ==
Devel subpackages need to setup some Requires:
Packages should try to make sure Haddock document links correctly to other dependent packages.


== Debug Information ==
<pre>
Debuginfo packages should not be built for GHC binaries, since they will be empty anyway.
%package -n ghc-%{pkg_name}-devel
Summary:        Haskell %{pkg_name} library development files
Requires:      ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:      ghc-%{pkg_name} = %{version}-%{release}
</pre>


''Rationale: GHC does not emit DWARF debug data.''
Lib packages need to use <code>%setup -n</code>:


== Macros ==
<pre>
%prep
%setup -q -n %{pkg_name}-%{version}
</pre>


A number of macros are defined for cabal packages, per compiler.  They have names like %ghc_build and %ghc_install. Similar macros can be defined for other compilers.  Please stick to this API when implementing macros for other compilers.
Both Lib and BinLib have:


* %cabal
<pre>
* %cabal_configure
%build
* %cabal_build
%ghc_lib_build
* %cabal_makefile
* %cabal_haddock
* %cabal_install
* %ghc_install_scripts
* %ghc_gen_filelists()
* %ghc_preinst_script
* %ghc_postinst_script
* %ghc_preun_script
* %ghc_postun_script


=== Definitions ===


Definitions per compiler go here
%install
%ghc_lib_install


* [[PackagingDrafts/Haskell/GHCMacroDefs | Definitions for GHC Macros ]]


== Spec Templates ==
%post devel
There are three types of packages: Library only, Library and Binary, and Binary only.  The program cabal-rpm can generate a SPEC file suited to all three cases.  The following templates are the output from cabal-rpm with a few minor changes.  These templates should build under mock, and any failure is a bug against these guidelines.
%ghc_pkg_recache


* [[PackagingDrafts/Haskell/LibraryOnlyTemplate|  Library Only Template]]
* [[PackagingDrafts/Haskell/BinaryOnlyTemplate|  Binary Only Template]]
* [[PackagingDrafts/Haskell/LibraryAndBinaryTemplate|  Library and Binary Template]]


== Static vs. Dynamic Linking ==
%postun devel
%ghc_pkg_recache
</pre>


Currently GHC performs only static linking with other Haskell libraries, partly due to a significant amount of optimizations done when inlining functions from other libraries. Therefore, when recompiling any library, all packages that depend on it will also need to be recompiled, and in the event of a security advisory, one needs to be applied to all dependencies.
<code>%ghc_lib_build</code> is used to configure, build and generate documentation for Lib and BinLib packages.  It runs:
* <code>%global debug_package %{nil}</code>: debuginfo is disabled since ghc's output is not in DWARF format.
* <code>%cabal_configure --ghc -p</code>: configures the package for building with ghc and profiling.  Libraries should build profiling versions of their static libraries.
* <code>%cabal build</code>: builds the package.
* <code>%cabal haddock</code>: 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 <code>without_haddock</code>.
** Additionally links to colored html sourcecode are also generated with <code>hscolour</code>, which can be disabled by defining <code>without_hscolour</code>.


This is not true for libraries linked through other languages using the Foreign Function Interface (FFI).  When linking to these libraries, the standard dynamic linker is used.
<code>%ghc_lib_install</code> is used to install Lib and BinLib packages.  It runs:
* <code>%cabal_install</code>: installs the package without registering it in ghc-pkg.
* <code>%cabal_pkg_conf</code>: creates ghc-pkg .conf metadata file for package installation time
* <code>%ghc_gen_filelists</code>: generates rpm filelists.
* <code>%ghc_strip_dynlinked</code>: strips dynamically linked objects.


''Note: this is very similar to OCaml, and the usual rules that apply there apply here as well.''
<code>%ghc_pkg_recache</code>: used in %post and %postun for devel subpackage - refreshes the ghc package cache database with .conf file data.


Keep in mind though, this does not mean that you can just put all dependencies in the BuildRequires list and be done with it.  Some packages, such as xmonad, perform lots of run time code generation, and may require certain libraries to be present to work.
== Directories ==
GHC libraries are installed under <code>%ghcpkgdir/%{pkg_name}-%{version}</code>:


== Using cabal-rpm ==
Library documentation lives under <code>%ghclibdocdir/%{pkg_name}-%{version}</code>.
If you use cabal-rpm to generate spec files, there are a few gotchas.  These items are the difference between Yaakov Nemoy's working cabal-rpm and the guidelines.  Since there is little variety in spec files, it might be easier to copy one of the templates from above and make the changes needed.


* The file name of the spec file will be the name of the package.  Make sure to prepend 'ghc-' or the appropriate name for another compiler to the spec file before submitting it for review.  This is necessary for libraries only.  (For example, there would be a collision between ghc-zlib and zlib, but there is only one haddock or darcs.)
== File lists ==
* cabal-rpm is currently only aware of haskell libraries installed by default with GHC.  It will need alot more work to provide automagic dependency detection.
Filelists for shared and devel library subpackages are generated through <code>%ghc_lib_install</code> using the macro <code>%ghc_gen_filelists</code>.
* cabal-rpm isn't always so intelligent about runtime dependencies for libraries.  For example, it may specify the devel version of a library where the non-devel version is required. (This is important for binaries only.  Libraries require devel versions, of course.)
* BuildRequires probably needs to be filled out by hand.  One suitable method is to keep testing it in mock until it compiles cleanly.
* If the source package requires steps besides cabal, report it to upstream, and make sure to include them in the %build and %install sections.


Double check the following:
It generates the filelists <code>ghc-%{pkg_name}.files</code> and <code>ghc-%{pkg_name}-devel.files</code>.


* License
== Compiling non-Cabal packages ==
* Group
Packages compiling Haskell code without Cabal, ie directly with <code>ghc</code> or <code>ghc --make</code>, should use <code>-O1</code> optimization, like Cabal does by default.
* URL - this can be the Hackage page
* Source URL - this can be from Hackage
* Summary
* Description
* Files section includes all documentation and LICENSES. If not, please patch it according to the Fedora Packaging Guidelines
 
Finally, make sure to include changelog entries to specify what has been changed from the original cabal-rpm output.


== References ==
== References ==
* http://urchin.earth.li/~ian/haskell-policy/ - Debian Haskell packaging policy
* http://fedorahosted.org/cabal2spec
* http://pkgs.fedoraproject.org/gitweb/?p=ghc-rpm-macros.git
* http://pkg-haskell.alioth.debian.org/haskell-policy/ - Debian Haskell packaging policy
* [[Packaging/OCaml|Fedora OCaml Packaging Guidelines]]
* [[Packaging/OCaml|Fedora OCaml Packaging Guidelines]]
* [[SIGs/Haskell|Fedora Haskell SIG]]
* [[SIGs/Haskell|Fedora Haskell SIG]]
* [http://ynemoy.fedorapeople.org/haskell Ynemoy's macros and cabal-rpm tree]
 
 
[[Category:Packaging guidelines]]

Latest revision as of 20:06, 21 December 2018

Warning.png
This is an old copy of a packaging guideline, preserved here in the wiki while we complete the transition to the Fedora documentation system. The current version is located at https://docs.fedoraproject.org/en-US/packaging-guidelines/Haskell/. Please update your bookmarks.

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 the current guidelines mostly focus on packaging for GHC using Cabal.

Spec file templates

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 only (Lib), binary only (Bin), and binary and library (BinLib):

Library Only

%global pkg_name @PACKAGE@

Name:           ghc-%{pkg_name}
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@

License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{pkg_name}
Source0:        http://hackage.haskell.org/packages/archive/%{pkg_name}/%{version}/%{pkg_name}-%{version}.tar.gz

BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros

%description
@DESCRIPTION@

%package devel
Summary:        Haskell %{pkg_name} library development files
Requires:       ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:       %{name} = %{version}-%{release}

%description devel
This package provides the Haskell %{pkg_name} library development files.


%prep
%setup -q -n %{pkg_name}-%{version}


%build
%ghc_lib_build


%install
%ghc_lib_install


%post devel
%ghc_pkg_recache


%postun devel
%ghc_pkg_recache


%files -f %{name}.files
%license LICENSE


%files devel -f %{name}-devel.files


%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm

Binary Only

Name:           @PACKAGE@
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@

License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{name}
Source0:        http://hackage.haskell.org/packages/archive/%{name}/%{version}/%{name}-%{version}.tar.gz

BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros

%description
@DESCRIPTION@


%prep
%setup -q


%build
%ghc_bin_build


%install
%ghc_bin_install


%files
%license LICENSE
%{_bindir}/%{name}


%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm

Library and Binary

%global pkg_name @PACKAGE@

Name:           %{pkg_name}
Version:        @VERSION@
Release:        1%{?dist}
Summary:        @SUMMARY@

License:        @LICENSE@
URL:            http://hackage.haskell.org/package/%{name}
Source0:        http://hackage.haskell.org/packages/archive/%{name}/%{version}/%{name}-%{version}.tar.gz

BuildRequires:  ghc-Cabal-devel
BuildRequires:  ghc-rpm-macros

%description
@DESCRIPTION@


%package -n ghc-%{name}
Summary:        Haskell %{name} library

%description -n ghc-%{name}
This package contains the Haskell %{name} library.


%package -n ghc-%{name}-devel
Summary:        Haskell %{name} library development files
Requires:       ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:       ghc-%{name} = %{version}-%{release}

%description -n ghc-%{name}-devel
This package provides the Haskell %{pkg_name} library development files.


%prep
%setup -q


%build
%ghc_lib_build


%install
%ghc_lib_install


%post -n ghc-%{name}-devel
%ghc_pkg_recache


%postun -n ghc-%{name}-devel
%ghc_pkg_recache


%files
%license LICENSE
%{_bindir}/%{name}


%files -n ghc-%{name} -f ghc-%{name}.files
%license LICENSE


%files -n ghc-%{name}-devel -f ghc-%{name}-devel.files


%changelog
* @DATE@ Fedora Haskell SIG <haskell@lists.fedoraproject.org>
- spec file generated by cabal-rpm

Package 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. However there may be cases where a Haskell BinLib package is really a Lib package with a minor or unimportant executable: in this case it is better to treat the package a Lib package, optionally with a executable subpackage if appropriate.

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

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 xmonad BinLib package has library subpackages

  • ghc-xmonad for the shared library, and
  • ghc-xmonad-devel for devel files and the static library.

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>

Cabal Flags

Cabal flags for build options should be set by changing the package's .cabal file: this can be done with the cabal-tweak-flag script to avoid having to carry and maintain patches for this. %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.

Dependency Generation

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

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

The cabal-tweak-dep-ver script can be used to bump versions of dependencies in the package .cabal file.

Shared and static library linking

GHC uses static libraries by default, but supports shared libraries on some architectures: currently i686 and x86_64. 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 most BinLib packages are currently staticly linked against the library in their own package (unless the .cabal file explicitly lists it as a dependency), but dynamically linked against other dependent libraries. BinLib executables that do link dynamically against their own library should use %ghc_fix_dynamic_rpath to fix its RPATH.

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. 

BuildRequires:  ghc-rpm-macros

The main commonly used macros are:

  • %ghc_bin_build
  • %ghc_lib_build
  • %ghc_bin_install
  • %ghc_lib_install

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

Bin packages

Bin package executables should be dynamically linked to shared Haskell libraries when available, but this can be overridden if necessary by defining the ghc_without_dynamic macro. 

%build
%ghc_bin_build


%install
%ghc_bin_install

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

  • %global debug_package %{nil}: debuginfo is disabled since ghc's output is not in GDB format.
  • %cabal_configure: configure the package for building and dynamic linking.
  • %cabal build: builds the package.

%ghc_bin_install is 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 should be dynamically linked to other shared Haskell libraries when available, but this can be overridden if necessary by defining the ghc_without_dynamic macro.

Devel subpackages need to setup some Requires: 

%package -n ghc-%{pkg_name}-devel
Summary:        Haskell %{pkg_name} library development files
Requires:       ghc-compiler = %{ghc_version}
Requires(post): ghc-compiler = %{ghc_version}
Requires(postun): ghc-compiler = %{ghc_version}
Requires:       ghc-%{pkg_name} = %{version}-%{release}

Lib packages need to use %setup -n: 

%prep
%setup -q -n %{pkg_name}-%{version}

Both Lib and BinLib have: 

%build
%ghc_lib_build


%install
%ghc_lib_install


%post devel
%ghc_pkg_recache


%postun devel
%ghc_pkg_recache

%ghc_lib_build is 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 defining without_hscolour.

%ghc_lib_install is 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_pkg_recache: used in %post and %postun for devel subpackage - refreshes the ghc package cache database with .conf file data.

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 through %ghc_lib_install using the macro %ghc_gen_filelists.

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

Compiling non-Cabal packages

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

References

Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Haskell&oldid=530779"