be2ba6d2e2
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9
https://github.com/containers/toolbox/issues/955
|
||
|---|---|---|
| .github | ||
| completion/bash | ||
| data | ||
| doc | ||
| images | ||
| playbooks | ||
| profile.d | ||
| src | ||
| test/system | ||
| .gitignore | ||
| .gitmodules | ||
| .zuul.yaml | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| GOALS.md | ||
| NEWS | ||
| README.md | ||
| SECURITY.md | ||
| gen-docs-list | ||
| meson.build | ||
| meson_options.txt | ||
| meson_post_install.py | ||
| toolbox | ||
README.md
Toolbox is a tool for Linux operating systems, which allows the use of containerized command line environments. It is built on top of Podman and other standard container technologies from OCI.
This is particularly useful on OSTree based operating systems like Fedora CoreOS and Silverblue. The intention of these systems is to discourage installation of software on the host, and instead install software as (or in) containers — they mostly don't even have package managers like DNF or YUM. This makes it difficult to set up a development environment or install tools for debugging in the usual way.
Toolbox solves this problem by providing a fully mutable container within
which one can install their favourite development and debugging tools, editors
and SDKs. For example, it's possible to do yum install ansible without
affecting the base operating system.
However, this tool doesn't require using an OSTree based system. It works equally well on Fedora Workstation and Server, and that's a useful way to incrementally adopt containerization.
The toolbox environment is based on an OCI
image. On Fedora this is the fedora-toolbox image. This image is used to
create a toolbox container that seamlessly integrates with the rest of the
operating system by providing access to the user's home directory, the Wayland
and X11 sockets, networking (including Avahi), removable devices (like USB
sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev
database, etc..
Installation & Use
See our guides on installing & getting started with Toolbox and Linux distro support.