rpms / toolbox

Clone
Source Code
GIT

#1 Add the toolbox-support and toolbox-experience subpackages
Closed 5 years ago by rishi. Opened 5 years ago by tpopela.
rpms/ tpopela/toolbox master  into  master

file modified
+70 
@@ -27,6 +27,72 @@ 
 

  Toolbox is offers a familiar RPM based environment for developing and
 

  debugging software that runs fully unprivileged using Podman.
 

  

+ # The list of requires packages for -support and -experience should be in sync with:
 

+ # https://github.com/debarshiray/toolbox/blob/master/images/fedora/f31/extra-packages

Seems like we'd want to make this canonical and just make the toolbox one more image that includes this subpackage.

 
+ %package       support
 

+ Summary:       Required packages for the container image to support %{name}
 

+ 

+ # These are really required to make the image work with toolbox
 

+ Requires:      passwd
 

+ Requires:      shadow-utils
 

+ Requires:      krb5-libs
 

+ 

+ %description   support
 

+ The %{name}-support package contains all the required packages that are needed
 

+ to be installed in the container image to make it work inside the %{name}.

this seems like taking %{name} too far :-) ... probably "with toolbox" is better too.

 
+ 

+ The %{name}-support should be typically installed from the Dockerfile if the
 

+ fedora-toolbox base image isn't used for the container.
 

+ 

+ 

+ %package       experience
 

+ Summary:       Set of packages to enhance the %{name} experience
 

+ 

+ Requires:      bash-completion
 

+ Requires:      bzip2
 

+ Requires:      diffutils
 

+ Requires:      dnf-plugins-core
 

+ Requires:      findutils
 

+ Requires:      flatpak-xdg-utils
 

+ Requires:      fpaste
 

+ Requires:      git
 

+ Requires:      gnupg
 

+ Requires:      gnupg2-smime
 

+ Requires:      hostname
 

+ Requires:      iputils
 

+ Requires:      jwhois
 

+ Requires:      keyutils
 

+ Requires:      less
 

+ Requires:      lsof
 

+ Requires:      man-db
 

+ Requires:      man-pages
 

+ Requires:      mlocate
 

+ Requires:      mtr
 

+ Requires:      openssh-clients
 

+ Requires:      PackageKit-command-not-found
 

+ Requires:      pigz
 

+ Requires:      procps-ng
 

+ Requires:      rsync
 

+ Requires:      sudo
 

+ Requires:      tcpdump
 

+ Requires:      time
 

+ Requires:      traceroute
 

+ Requires:      tree
 

+ Requires:      unzip
 

+ Requires:      vte-profile
rishi commented 5 years ago

After playing with the TensorFlow toolbox, I realized that vte-profile should be moved to the support sub-package. Otherwise, we keep getting this error in Bash:

bash: __vte_prompt_command: command not found

vte-profile is just 10 kB in size, has literally no dependencies and only carries /etc/profile.d/vte.sh.

 
+ Requires:      wget
 

+ Requires:      which
 

+ Requires:      words
 

+ Requires:      xz
 

+ Requires:      zip
 

+ 

+ %description   experience
 

+ The %{name}-experience package contains all the packages that should be installed
 

+ to the container to provide the same default experience as working on the host.
 

+ 

+ The %{name}-support should be typically installed from the Dockerfile if the
rishi commented 5 years ago

Typo lalert: should be %{name}-experience. :)

 
+ fedora-toolbox base image isn't used for the container.
 

+ 

  

  %prep
 

  %autosetup
 
@@ -54,6 +120,10 @@ 
 

  %{_mandir}/man1/%{name}-*.1*
 

  %{_tmpfilesdir}/%{name}.conf
 

  

+ %files support
 

+ 

+ %files experience
 

+ 

  

  %changelog
 

  * Thu Mar 14 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.7-1

These are intended to be installed into the image if the image doesn't
use the fedora-toolbox container as the base image - all the packages
are already preinstalled there.

The support subpackage should be installed to images that intent to work flawlessly
with toolbox.

The experience subpackage should be installed as well, to
provide the same experience while working in the container as one would
get on the host.

What are the circumstances when you wouldn't use the toolbox container as the base image?

I didn't put an explicit require from the experience to support subpackage. If you want me to, then I could add it, but maybe let the users be explicit about it.

What are the circumstances when you wouldn't use the toolbox container as the base image?

So main motivation here was that I was trying the Tensorflow image and it's based on the regular F29 image. There were some problems (now fixed) with the toolbox image that were preventing the TF image to be build successfully. At that point I reached to Rishi to see what's actually needed.

I can imagine that people will be basing their images on other images that could be already based on something else (not a toolbox one, not a regular Fedora one), so we should have a way for them to enable the toolbox support easily - instead of pursuing the creator of their image to have it based on the toolbox image.

So main motivation here was that I was trying the Tensorflow image
and it's based on the regular F29 image. There were some problems
(now fixed) with the toolbox image that were preventing the TF image
to be build successfully. At that point I reached to Rishi to see what's
actually needed.

Since the TensorFlow image was based on the fedora:N image, it didn't have passwd. This broke toolbox create --image ... because it couldn't customize the image for the local user in order to create the toolbox container. It was fixed by either basing the TensorFlow image on the fedora-toolbox:N image or layering the passwd RPM separately.

I can imagine that people will be basing their images on other images
that could be already based on something else (not a toolbox one, not a
regular Fedora one), so we should have a way for them to enable the
toolbox support easily - instead of pursuing the creator of their image to
have it based on the toolbox image.

Related to that, I'd like to add a page documenting what a toolbox image should look like. When it comes to the package requirements, currently we'd have to say: keep monitoring this list of RPMs in toolbox.git, and ensure that your image has them.

Instead, it might be more convenient to say: install this one RPM in your image, and as the toolbox evolves, rebuilding your images will be enough to pick up the necessary adjustments.

Since the TensorFlow image was based on the fedora:N image, it didn't have passwd. This broke toolbox create --image ... because it couldn't customize the image for the local user in order to create the toolbox container. It was fixed by either basing the TensorFlow image on the fedora-toolbox:N image or layering the passwd RPM separately.

Also there was the other problem with that dnf cache left in the toolbox base image. And it was preventing the TF image to get build. But at that point the only solution was use the regular Fedora image and manually install the passwd.

Seems like we'd want to make this canonical and just make the toolbox one more image that includes this subpackage.

this seems like taking %{name} too far :-) ... probably "with toolbox" is better too.

this seems like taking %{name} too far :-) ... probably "with toolbox" is better too.

We are ready for the next rename ;). I don't have a string preference here.

Seems like we'd want to make this canonical and just make the toolbox one more image that includes this subpackage.

Yes, that's the plan. For everything that is "official" from toolbox POV we will require the toolbox-support and toolbox-experience to be included there. But for local toolbox development we will still use the extra_packages as currently as it's a way faster than to build the package locally. Also we have to take in mind that every change to the list of the packages will needs to be build, it has to hit the repos before we build any official image that should include that particular changes introduced to the toolbox-* packages.

After playing with the TensorFlow toolbox, I realized that vte-profile should be moved to the support sub-package. Otherwise, we keep getting this error in Bash:

bash: __vte_prompt_command: command not found

vte-profile is just 10 kB in size, has literally no dependencies and only carries /etc/profile.d/vte.sh.

Typo lalert: should be %{name}-experience. :)

I took the liberty to tweak as above and merged! Thanks @tpopela

Looks like Pagure didn't realize that I had merged through the command line. Closing.

Pull-Request has been closed by rishi
5 years ago
Changes Summary 1
+70 -0
file changed
toolbox.spec
Powered by Pagure 5.13.3
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.