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

[Mateusz Kowalczyk]

On 08/10/2014 10:40 PM, Peter Simons wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

OK, that's a great answer, thanks! One remaining question I have is
about whether we should be attempting to make failing packages build.
Consider the log at [1]. It seems like it would be easy to fix with a
patch file doing the extra imports or whatever it takes. Is doing this
encouraged? It's not a nix problem so it seems we shouldn't implement a
fix ourselves. For now I marked that package as broken and sent an
e-mail to the maintainer.

[1]: http://hydra.cryp.to/build/164802/log/raw

-- 
Mateusz K.