systemd-nspawn can react to SIGTERM and send a shutdown signal to the container
init process. use that instead of going through dbus and machined to request
nspawn sending the signal, since during host shutdown machined or dbus may have
gone away by the point a container unit is stopped.
to solve the issue that a container that is still starting cannot be stopped
cleanly we must also handle this signal in containerInit/stage-2.
Patch every `derivation` call in the bootsrap process to add it a
conditional `__contentAddressed` parameter.
That way, passing `contentAddressedByDefault` means that the entire
build closure of a system can be content addressed
Provides a few hopefully helpful pointers that would not work well as
inline comments in the expressions themselves. Most likely the README
will need to be expanded upon over time to cover how we handle the Julia
release process, but I hope this is a good starting point.
Provides very little comfort compared what is outlined in the
manual [1], only supports a single version, and would probably be better
to implement as a general Nixpkg tool.
[1]: https://nixos.org/manual/nixpkgs/stable/#sec-source-hashes
As far as I can tell this patch is redundant as all pre-compiled code
generated at build time is baked into the Julia system image and will
thus never get invalidated: Note that for both julia_10 and julia_15
there are no `.ji` files produced in the derivations.
This is potentially controversial, but it is unclear to me whether
julia_1 should refer to either the latest stable or LTS release of 1.x.
We may want to revisit this when/if we get 2.x, but as it stands the
Julia release process [1] makes it clear that there will only ever be a
single supported stable and LTS release at any given time which should
speak in favour of using the julia-stable and julia-lts aliases instead.
[1]: https://julialang.org/blog/2019/08/release-process/#long_term_support
According to the Julia release process [1] there will only ever be two
supported release branches at any given time: stable and LTS. Once a new
version of either is released, support for the previous release will be
dropped upstream. Introducing aliases for these branches allows our
users to easily track either depending on their need for stability.
[1]: https://julialang.org/blog/2019/08/release-process/#long_term_support
