These files are pure data, just fonts; they shouldn't have been moved
to the "perl" output, because the Perl programs (namely, gropdf) use
them from the main "out" output.
These files don't contain any references to more dependencies (Perl or
otherwise), so they don't bloat the closure. And the files themselves
are small; 276K total as of this commit.
This package hasn't seen a release in about 9 years, and there are
important features on master (namely, Unix socket support), so we'll
get our version from Github.
This plugin allows configuring the URLs generated by Catalyst (and
therefore by Hydra) to be relative instead of absolute, which makes it
automatically behave correctly when Hydra is accessed both directly
and behind a reverse proxy.
gnupg is gnupg 2.2. gnupg1 is also gnupg 2.2, just with a few extra
symlinks in the bin directory. None of these packages need those
symlinks, and it's confusing for them to say they're depending on
"gnupg1", so switch their dep to plain "gnupg".
This is more newbie-friendly; a user without much Nix knowledge would
"nix search" for xmonad, see xmonad-with-packages, and just
immediately install it. This basically never works because most xmonad
users use xmonad-contrib. If we add xmonad-contrib to the packages
list for xmonad by default, then the new user's straightforward action
will just work, most of the time.
People are confused when they "nix search" for xmobar (a standalone
application which just happens to be written in Haskell) and don't
find it; they assume xmobar is not actually packaged. They have to
have special Nix knowledge to know that they should look in
haskellPackages for xmobar.
Let's just put xmobar in all-packages.nix so it shows up in search,
and people can install it straightforwardly without knowing about
haskellPackages.
This setupHook is necessary for actually using pkgconfig. Without this
setupHook, you need to put both pythonPackages.pkgconfig and pkgconfig
into your buildInputs, just to get the setuphook of the latter.
Previously, pythonPackages.pkgconfig depended on pkgconfig as a
propagatedBuildInput, so this setupHook was propagated down to
dependents. That was changed to a regular nativeBuildInput, so now
this setupHook change is necessary for packages to only depend on
pythonPackages.pkgconfig.
A possible alternative is extracting out a common pkgconfigHook
package and having both pythonPackages.pkgconfig and pkgconfig depend
on that with propagatedBuildInputs. That might be necessary to avoid
the buildHook running twice?
It's not necessary to depend on the "typing" backport since it's in
the standard library; I also observed serious breakage in anything
using the typing module (including) when the backport was in the
closure on >=3.5.
This "with" usage makes it trickier to track where the actual source
package of this derivation comes from. Remove that use of with to make
it a little easier to understand.
Spencer Baugh