We track the git version, because haskell-mode does not provide regular
releases except via MELPA, which our Emacs infrastructure does not support yet.
This used to be added by cabal2nix, but now the tool no longer does because
there's no reliable way to refer to the patch file in the generated build
expression.
This update greatly enhances the accuracy with which dependencies are expressed
in the generated Nix files. Previous versions distinguished dependencies for
building ("buildDepends") and testing ("testDepends"). This distinction didn't
apply to system packages or build tools, however: the fields "extraLibs" and
"buildTools" applied to the entire build. This meant that dependencies required
only for testing would be pulled in regardless of whether the test were
actually being run, etc.
These days, we distinguish dependencies for libraries, executables, and tests,
and for each of those types we distinguish dependencies on Haskell libraries,
system libraries, pkgconfig libraries, and build tools. This gives us a
whopping 12 new attributes
xxxHaskellDepends
xxxSystemDepends
xxxPkgconfigDepends
xxxToolDepends
where "xxx" is any of "library", "executable", or "test".
The old dependency attributes are no longer generated by cabal2nix. The generic
builder in Nixpkgs still accepts them, though, for the sake of backwards
compatibility. This means that you don't have to re-generate all your build
expressions with the new version, but you *should*.
For example, this allows writing
nix.package = /nix/store/786mlvhd17xvcp2r4jmmay6jj4wj6b7f-nix-1.10pre4206_896428c;
Also, document types.package in the manual.
This reverts commit 37ff33196f.
This can't be it. `lcms` and `lcms2` are two entirely different packages.
Furthermore, the dependency is propagated through colord and should be
fixed there, if needed.
Fixes errors when attempting to decrypt an encrypted message.
I'm not sure that `crypto.c` needs to be patched after this, since this setting
should propagate there, but let's play it safe.