- Removes the non-slim build instructions, massively simplifying
everything in the package.
- Removes unecessary patches.
- Inherits functions from lib instead of repeating lib.* everywhere.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
As the builder is generic, more people may be using it, so we should try
to keep this value as close to the upstream source of truth as possible.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
This adds convenience writers for self-contained Nim programs.
Those are compiled into very small binaries.
Test with: `nix build .#pkgs.tests.writers.{bin,simple,wrapping}.nim`
`makeWrapper` is often used in these with `source "${makeWrapper}/nix-support/setup-hook"`
which causes `error: makeWrapper/makeShellWrapper must be in nativeBuildInputs` on cross.
Prior to this commit it was not possible to modify e.g. the list of ignored directories at all, however given that `buildFHSEnvBubblewrap` effectively uses a sandboxing tool (*bwrap*) I feel like this is a missed opportunity.
The code in nixpkgs already covers all the knobs that are required to get *Nix* itself to run inside bubblewrap, so why not allow users to make that additional modification?
While additional `ro_mounts` and such can be *added* to the bubblewrap invocation, the already mounted directories cannot be removed, and even if shadowed by e.g. a tmpfs mount, this would still allow something inside the sandbox to potentially unmount the tmpfs and access the data.
So what this change does is moving the snippet where custom code can be injected down by four lines so that users can actually modify those variables e.g. using `ignored+=( /home /srv /mnt /boot )`.
The only cases in which this would break is:
- someone using those variable names in `extraPreBwrapCmds` already and relying on them being overwritten; I would consider that chance slim, and the fix would be easy enough
- someone using a construct like `false && \` to disable the `ignored` initialisation and effectively working around this limitation; again the chances are slim (even though I know I'd be affected), and the fix would be easy enough (as this change makes the workaround needless anyway so it's an improvement)
Signed-off-by: benaryorg <binary@benary.org>
Setting the image creation timestamp in the image metadata to a
constant date can cause problems with self-hosted container
registries, that need to e.g. prune old images. This timestamp is
also useful for debugging.
However, it is almost never useful to set the filesystem timestamp to
a constant value. Doing so not only causes the image to possibly no
longer be reproducible, but also removes any possibility of
deduplicating layers with other images, causing unnecessary storage
space usage.
Therefore, this commit introduces "mtime", a new parameter to
streamLayeredImage, which allows specifying the filesystem timestamps
separately from "created". For backwards compatibility, "mtime"
defaults to the value of "created".
