[Nix-dev] How to help remedy build errors of Haskell packages in Nixpkgs

Peter Simons simons at cryp.to
Sun Aug 10 22:40:49 CEST 2014


Hi Mateusz,

 > Say a package version no longer builds with <recent GHC version> and
 > upstream won't fix it or can't fix it to work with that version for
 > some reason, what's the way to go about only blacklisting the broken
 > GHC versions?

Hydra builds Haskell packages only with the "latest stable release" of
GHC, which is 7.8.3 at the moment. Packages that don't compile with that
particular compiler should not request a Hydra build. That is
accomplished by adding the attribute

  hydraPlatforms = self.stdenv.lib.platforms.none;

to the "meta" section of the Nix expression. It's okay to make that
change manually to the expression -- hackage4nix will keep that choice
intact when re-generating the file.

 > What [is] the recommended way to edit the Haskell package expressions.

Personally, I don't use a compiled version of cabal2nix. I have a
checked-out copy of the cabal2nix repository lying around in my home and
use wrapper scripts to run the tool directly from source code. (The
scripts are attached to the end of this message for your information.)

Now, some attributes can be changed manually in the Nix expression
directly without going through cabal2nix. Those attributes are:

 - doCheck
 - noHaddock
 - jailbreak
 - meta.maintainers
 - meta.platforms
 - meta.hydraPlatforms

When hackage4nix is run, it will always try to extract the current
values for those attributes from the expressions found in Nixpkgs and
re-use in the re-generation process. As a rule of thumb, you can make
edits to a Haskell expression, and then run hackage4nix ~/src/nixpkgs to
check that your changes are not overwritten. (I explained that workflow
in more detail in my previous message.) If the changes remain untouched,
everything is fine.

Furthermore, the following attributes can be edited manually in Nix
expressions if the values apply only to the particular version of the
package that you're editing:

 - {pre|post}Configure
 - {pre|post}Install
 - patchPhase
 - patches
 - meta.broken

If hackage4nix sees any of those attributes in a Nix expression, it will
not touch the file, so these values will never be overwritten. When the
package is updated, however, these values will be lost!

A typical use-case is this: suppose package "Foobar" has a bug that can
be fixed by running a simple 'sed' command in the patchPhase hook. If
that patch is added to the Nix expression, then it will stay in there,
but when the new version comes out, the patch will be gone -- which is
the behavior you want because you've reported that bug upstream and the
next release will fix it, right? :-)

Last but not least, there are attributes that you cannot change manually
at all. Those are:

 - buildDepends
 - buildTools
 - extraLibraries
 - pkgconfigDepends
 - testDepends

Any change to these attributes will be lost when hackage4nix
re-generates the file. If you want to mess with the contents of these
attributes, then you must modify the cabal2nix source code. The
following types of patches occur most frequently:

 - A cabal file calls a system library "libfoo", but in Nixpkgs that
   library is called "foo", so the generated Nix file comes out with a
   function argument that cannot be resolved. This type of issue can be
   fixed by passing an appropriate override in the haskell-packages.nix
   file, or, preferably, by adding an appropriate mapping to:

     https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/Name.hs

 - You want enable a Cabal flag that's not enabled by default (or
   disable one that's enabled by default). This is simply a matter of
   adding the configuration for the package to:

     https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/Flags.hs

 - The Cabal file is outright broken, i.e. it doesn't specify all
   required build tools (for example: Perl, cpphs, etc. are missing
   frequently), it specifies an incorrect set of dependencies, etc. Now,
   this kind of stuff must be reported upstream, obviously, but you can
   work around these issue by messing with the generated build
   instructions in the post-process hook at:

     https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/PostProcess.hs

I hope this helps,
Peter


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cabal2nix
Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140810/084940fb/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hackage4nix
Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140810/084940fb/attachment-0001.pl 


More information about the nix-dev mailing list