Howdy Y'all,
Just a heads up that "Toolbox" is ready to be reviewed, let me know if anything looks odd or needs fixing.
Thank you,
On Wed, 2019-11-06 at 05:37 +0000, Ryan Walter wrote:
Howdy Y'all,
Just a heads up that "Toolbox" is ready to be reviewed, let me know if anything looks odd or needs fixing.
I had been using mock --shell for a similar purpose. How does toolbox compare to mock? I can see several details from your article, e.g. the toolbox containers write to your home, so no --copyin, --copyout required and toolbox seems from your examples to control only what is installed on the system - very handy for installing BRs to use rpmbuild. Also, toolbox seems to be able to keep several containers, while mock seems to have only one that gets cleared and reused.
But I feel like mock provides some measure of protection when building new packages - without going full VM. I'm not sure I like toolbox writing to HOME.
Howdy Stuart,
I have not used mock --shell. So I cannot compare, perhaps if I elaborate the original use case of toolbox it would help explain the design choices and help you decide if it's the right tool for you.
Toolbox was created by the Silverblue team. Silverblues design philosophy is that your base system is made out of images. You can roll back and forward on these images to reach a predetermined state, this helps with rolling back updates if one goes sour.
The biggest crux of rpm-ostree (Silverblues system image system) is that rpm-ostree has a subset of features of DNF, you also are required to reboot your system for each update or installation of packages. Silverblue embraces this and their typical application workflow works around Podman and Flatpak, which are container applications for use with nonroot interaction and GUI applications.
You can emulate toolbox with podman run --name toolbox -v /home:/home fedora && podman exec --name toolbox /bin/bash, however not all aspects of your base system will translate across.
Toolbox streamlines the process of mounting home, passing your env vars, and running the podman commands. This will give you an envioment that is similar to a non rpm-ostree based system. Your application installed here will not require reboots.
We can utilize toolbox on Workstation and Server as well. It works particulary well if you do not have root or install access or would like to separate your build system from your desktop install. Since you don't have to worry about copying back and you don't have to worry about losing source or build files. (Or whatever your tool does, could run FFMpeg for example)
Hope this helps. The use case I show in the article (building a resume with Pandoc, make, and a whole group of packages) prevents about 400 extra packages from being installed on my desktop.
Cheers
Rwaltr
-------- Original Message -------- On Nov 6, 2019, 8:27 AM, Stuart D. Gathman wrote:
On Wed, 2019-11-06 at 05:37 +0000, Ryan Walter wrote:
Howdy Y'all,
Just a heads up that "Toolbox" is ready to be reviewed, let me know if anything looks odd or needs fixing.
I had been using mock --shell for a similar purpose. How does toolbox compare to mock? I can see several details from your article, e.g. the toolbox containers write to your home, so no --copyin, --copyout required and toolbox seems from your examples to control only what is installed on the system - very handy for installing BRs to use rpmbuild. Also, toolbox seems to be able to keep several containers, while mock seems to have only one that gets cleared and reused.
But I feel like mock provides some measure of protection when building new packages - without going full VM. I'm not sure I like toolbox writing to HOME.
magazine@lists.fedoraproject.org