[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ next ]
It is strongly recommended that only cabalised libraries are
packaged. If you wish to package a non-cabalised library then the recommended
approach is to first cabalise it, forwarding the patch upstream.
Cabal package names match the regex [a-zA-Z][-a-zA-Z0-9]*, and the tools that manipulate them are case preserving only. For your package, calculate the cname from the Cabal package name by converting all uppercase letters to lowercase. If it is desirable for multiple versions of the same cabal package to be installed at once on a Debian system then you may append -cversion, where cversion is the cabal version, to cname.
The Debian source package should be called libcname and, for each implementation impl that it is built for, it should make a libimpl-cname-dev binary package. XXX this needs more thought.
If multiple cabal packages are in a single upstream tarball, and repacking them separately does not seem sensible then a suitable source package name should be chosen instead. A separate binary package for each cabal package, following the naming scheme above, should still be created.
Some Haskell compilers, such as GHC, perform cross-module optimisations, such as inlining. This means that even small internal changes to a library foo can cause programs that link with a library bar which, in turn, uses foo to fail to link, or even to link successfully but give incorrect results. Therefore libraries must depend on the exact version of other Haskell libraries that they were compiled against. Furthermore, they must build-depend on the exact version of the Haskell libraries they use in order to keep the packages in sync across all arches.
An exception is made for the libraries shipped with compilers. The reasons for this are:
Many of the libraries currently shipped with compilers will be used by very few libraries. Should a library need to be changed in a Debian release the compiler package must conflict with those packages affected.
While an upload of a library to fix other packaging issues will result in only a handful, at most, of packages needing to be (needlessly) recompiled, such an upload of a compiler would require all libraries to be (needlessly) recompiled.
Thus we believe this policy gives the best tradeoff between maintainers having to be careful about conflicts when they make changes and not wasting too many CPU cycles on unnecessary recompilation.
For simplicity's sake we will use this dependency scheme for all Haskell
implementations. As almost all libraries are expected to be compiled for GHC
this should not affect when recompilation is necessary. All Haskell
implementations must provide a file
/usr/lib/compiler/debian-dependencies that contains how the
library must depend on the compiler, e.g. ghc6 (>= 6.2.1), ghc6
(<< 6.2.1+).
The possibility of compiling libraries at install time was considered, but was rejected due to its fragility and due to it being against the spirit of Debian being a binary districution.
All libraries should be built for all released compilers in Debian for which they are buildable. Libraries should not be built for unreleased compilers, such as CVS snapshots, without good reason, as uploads of new versions of these would require new uploads of all such libraries, and their reverse dependencies, too. However, you can upload libraries built against unreleased compilers to Haskell Unsafe.
Although there is no technical reason why all libraries need be in the same
place, in order to make life easier for users all libraries should be
installed into /usr/lib/haskell-libraries/compiler/package/ where
compiler is the source package name of the compiler they are to be
used with.
For each cabal package cp, a manual page
cp.3haskell describing the purpose of the package and
the list of modules it includes should be installed into
/usr/share/man/man3. Additionally, for each module
Hierarchial.Module, a manual page
cp.Hierarchial.Module.3haskell dsecribing
the purpose and interface of the module should be installed into
/usr/share/man/man3. XXX We'd like to mention haddock here, but
it can't output manual pages yet, can it?
Additionally, you should provide documentation in other formats such
as, but not limited to, plain text and HTML in
/usr/share/doc/package. It is expected that most libraries will
provide documentation in the form accepted by haddock, making this easy.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ next ]
Haskell Policy
0.1.6igloo@earth.li