Adds the static overlay that can be used to build Nixpkgs statically.
Can be used like:
nix build pkgsStatic.hello
Not all packages build, as some rely on dynamic linking.
This is kind of a mess, but basically:
- static=true, shared=true means to build statically but move it to
the static output
- static=true, shared=false means to build statically and leave it in
the main output
- static=false, shared=true means to not build static at all
Confusingly, the old default was static=true, shared=true even though
static=false? Still can’t figure out what was meant by that.
Nixpkgs is meant to link everything dynamically. We don’t want to
expose static packages at the top level. If some package needs
statically built binaries, it should use a custom override.
crossOverlays only apply to the packages being built, not the build
packages. It is useful when you don’t care what is used to build your
packages, just what is being built. The idea relies heavily on the
cross compiling infrastructure. Using this implies that we need to
create a cross stdenv.
This cleans up the CockroachDB expression, with a few suggestions from
@aszlig.
However, it brought up the note of using systemd's StateDirectory=
directive, which is a nice feature for managing long-term data files,
especially for UID/GID assigned services. However, it can only manage
directories under /var/lib (for global services), so it has to introduce
a special path to make use of it at all in the case someone wants a path
at a different root.
While the dataDir directive at the NixOS level is _occasionally_ useful,
I've gone ahead and removed it for now, as this expression is so new,
and it makes the expression cleaner, while other kinks can be worked out
and people can test drive it.
CockroachDB's dataDir directive, instead, has been replaced with
systemd's StateDirectory management to place the data under
/var/lib/cockroachdb for all uses.
There's an included RequiresMountsFor= clause like usual though, so if
people want dependencies for any kind of mounted device at boot
time/before database startup, it's easy to specify using their own
mount/filesystems clause.
This can also be reverted if necessary, but, we can see if anyone ever
actually wants that later on before doing it -- it's a backwards
compatible change, anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
* kodi-cli: init at 1.1.1 (#50892)
* kodi-cli: nitpicks
nitpicks applied are:
- The pname thing
staging-next has been merged.
- Moved to tools/misc
applications/video is more appropriate for video applications.
This is a script used to interact with one.
- Changed platforms to unix
This script can only be used where kodi is present.
