Toolbox is being increasingly used outside the Fedora universe. Endless
OS already uses it, and there's some interest in using it on Arch
Linux, Red Hat Enterprise Linux and Ubuntu. Therefore, it's a good
idea to clearly document what's necessary for a smooth Toolbox user
experience on a given operating system distribution.
Note that this might not match the current reality of the code, which
is predominantly developed, tested and used on Fedora. This is a step
towards formally specifying what an OS distributor is expected to
provide. The code can then be iteratively improved to match the
specification.
https://github.com/containers/toolbox/pull/300
Toolbox is being used with Endless OS, which is an OSTree based
operating system built out of Debian packages, not RPMs; and in the
Fedora universe, CoreOS is being increasingly treated as a primary
use-case for Toolbox alongside Silverblue.
https://github.com/containers/toolbox/pull/299
This works by configuring the toolbox container after it has been
created, instead of before. The toolbox script itself is mentioned as
the entry point of the container, which does 'exec sleep +Inf' once the
initialization is done.
A new command 'init-container' was added to perform the initialization.
It is primarily meant to be used as the entry point for all toolbox
containers, and must be run inside the container that's to be
initialized. It is not expected to be directly invoked by humans, and
cannot be used on the host.
As a result, the default name for the toolbox containers is now
fedora-toolbox-<version-id>, not fedora-toolbox-<user>-<version-id>.
For backwards compatibility, 'toolbox enter' and 'toolbox run' will
continue to work with containers using the old naming scheme.
https://github.com/debarshiray/toolbox/pull/160
The "fedora" prefix was used because this project was specifically
incubated to make it easier to hack on Fedora Silverblue. That and the
mix of upstream technologies (ie., Buildah and Podman) made it uniquely
"Fedora".
However, over time it has gotten clear that other groups, currently
Fedora downstreams like RHEL, are interested in it too. It won't be
surprising if in future it transcends the Fedora universe altogether.
Moreover, this project was inspired by coreos/toolbox [1]. There are
good reasons and enough interest to have a unified toolbox project
that addresses the needs of both Fedora CoreOS and Silverblue.
Therefore, it is best to drop the "fedora" prefix and call the whole
thing just "toolbox".
No extra effort was made to retain compatibility with the older name
due to the project's young age. Its userbase is limited to the earliest
of early adopters, and the benefits of a clean break outweigh the
loss of compatibility.
The OCI images and the toolbox container still retain the "fedora"
prefix to disambiguate them from their counterparts from other
operating systems.
[1] https://github.com/coreos/toolboxhttps://github.com/debarshiray/toolbox/issues/8
- OSTree systems aren't fully immutable, you *can* install things
we just discourage it
- fedora-toolbox can (and should!) be used on non-OSTree based
systems as well
https://github.com/debarshiray/fedora-toolbox/pull/43
Simplify the prompt. Most people are going to use the Fedora package.
Hence, the prompt doesn't need to reflect the fedora-toolbox Git tree
as the current directory.
The base fedora-toolbox images for Fedoras 28, 29 and 30 are now
available from registry.fedoraproject.org. Hence it's no longer
mandatory to build them locally. If they are built locally, then the
local images will be preferred over the ones from the registry.
https://pagure.io/releng/issue/7874
It would be good to have Dockerfiles for multiple Fedora versions, and
possibly even other operating systems like Red Hat Enterprise Linux or
CentOS, so that people can use the toolbox on different host OSes.
In the future, it would be nice to have multiple toolbox containers
corresponding to different OSes exist side by side. One could then
have a Fedora 29 environment on a Fedora 28 host and so on.
