In #19309 a separate output for tkinter was added.
Several dependencies of Python depend indirectly on Python. We have the
following two paths:
```
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘libXrender-0.9.10’ -
‘libX11-1.6.4’ - ‘libxcb-1.12’ - ‘libxslt-1.1.29’- ‘libxml2-2.9.4’ -
‘python-2.7.12’
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘fontconfig-2.12.1’ -
‘dejavu-fonts-2.37’ - ‘fontforge-20160404’ - ‘python-2.7.12’
```
Because only `tkinter` needs this, I added
```
pythonSmall = python.override {x11Support = false;};
```
to break the infinite recursion. We also still have the output
`tkinter`.
However, we might as well build without x11Support by default. Then we build with x11Support as well so we get the tkinter module and put that in a separate package.
Regression introduced by da36847d92.
The kernelPackages NixOS module option now uses .override to add kernel
patches defined in boot.kernelPatches into the kernel within the
kernelPackages set.
For generic kernels, we already have an .override which comes with
callPackage, but pkgs.linuxManualConfig is a function where we want to
override the attributes passed to it.
The callPackage to manual-config.nix only allows us to override its
internal attributes but not the attributes of the function returned.
Simplified it looks like this:
.----- .override provided by
__|__ callPackage
| |
(callPackage .../manual-config.nix { ... }) { ... }
|_____|
|
the one -----'
we actually want to override
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This also updates a bunch of its dependencies to enable the update,
and gets rid of libhif because upstream stopped maintaining it as
such, instead using it internally in other projects until they can
agree on an interface for it. Nothing seemed to be using libhif so
I'm not too concerned about removing it.
We are currently carrying a number of vala versions where each version
is essentially just a copy of the earlier version.
This PR gets rid of a ton of duplication and uses a standard builder.
Secondly, we add a definition for the latest vala 0.34.1.
Lastly, we add a generic "vala" that refers to the latest stable
version.
I have tried changing the definitions for "simple-scan" and "valum" to use
the latest vala version and they at least compile OK so I'll try a
massive sed job to replace all the definitions later to simply use the
latest version through "vala" instead of specifying a version directly.
According to upstream:
"Well-maintained packages are expected to always build with the latest
stable Vala version."
Maybe this means that my generic builder is then no longer necessary. Oh well...
I added myself to the maintainer array for vala although I have no
interest in the language - this was purely a nix exercise for me but I
thought it was reasonable to be the one to clean up the mess if this has
side effects...
Cc: @antono and @lethalman
