Commit graph

14 commits

Author SHA1 Message Date
Timothée Ravier
9506173f88 images: Don't leak NAME and VERSION into the Toolbx container
Note that there can be only one ARG per line.  Otherwise, the build may
fail with some build systems.  eg., Fedora's [1], which uses Docker, not
Podman.

Only the images for currently maintained Fedoras (ie., 36, 37, 38 & 39)
were updated.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=98150241

https://github.com/containers/toolbox/issues/188
2023-03-01 17:06:58 +01:00
Debarshi Ray
470a15ff71 images: Synchronize README.md
The canonical copy of README.md contains banners and labels in the
header that aren't useful when the file is shipped as part of the
images.  Hence, those were removed.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

https://github.com/containers/toolbox/pull/1231
2023-02-07 20:46:38 +01:00
Debarshi Ray
707607d839 images: Ensure that the gpg2(1), gnupg2(7), etc. manuals are available
It turns out that at least since Fedora 30 [1], the gnupg2 package has
been part of the fedora base image, because it's required by the dnf
package:
  dnf -> python3-dnf -> python3-libdnf -> libdnf -> gpgme -> gnupg2

Hence, the need to restore the gnupg2 documentation that was stripped
out in the base image.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

[1] It's difficult to find out if the gnupg2 package wasn't part of the
    fedora base image before Fedora 30, because those images are no
    longer available from registry.fedoraproject.org.

https://github.com/containers/toolbox/pull/1228
2023-02-02 17:25:31 +01:00
Debarshi Ray
d22fa5b731 images: Use the package name instead of a virtual Provides for gnupg2
The package for GnuPG 2.0 has always been called gnupg2 [1], so this
must have been a mistake.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

Fallout from 34bfd0317d

[1] https://pagure.io/fedora-comps/blob/main/f/comps-f21.xml.in

https://github.com/containers/toolbox/pull/1228
2023-02-02 16:52:45 +01:00
Debarshi Ray
4f907d32f3 images: Ensure that the kill(1), mount(8), etc. manuals are available
Note that in the past, it was observed that the util-linux package was
no longer part of the fedora base images starting from Fedora 35 [1],
and indeed it wasn't [2].  However, later the util-linux-core subset was
restored from Fedora 36 onwards [3].  Hence, the need to restore the
util-linux-core documentation that was stripped out in the base image.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

Original patch from Jens Petersen for Fedora [4].

[1] Commit df05e276b2
    https://github.com/containers/toolbox/issues/929

[2] fedora-kickstarts commit 1f3645b72d46a0a7
    https://pagure.io/fedora-kickstarts/c/1f3645b72d46a0a7
    https://bugzilla.redhat.com/show_bug.cgi?id=1951111

[3] fedora-kickstarts commit 4477181faf75e105
    https://pagure.io/fedora-kickstarts/c/4477181faf75e105

[4] Fedora fedora-toolbox commit 805dc32c280b10f3
    https://src.fedoraproject.org/container/fedora-toolbox/c/805dc32c280b10f3

https://github.com/containers/toolbox/pull/1227
2023-02-01 21:57:01 +01:00
Debarshi Ray
a2ef3a292c images: Ensure that the cat(1), cp(1), ls(1), etc. manuals are available
Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

Original patch from Jens Petersen for Fedora [1].

[1] Fedora fedora-toolbox commit 98d9106a1f2f7a30
    https://src.fedoraproject.org/container/fedora-toolbox/c/98d9106a1f2f7a30

https://github.com/containers/toolbox/pull/1226
2023-02-01 19:26:36 +01:00
Debarshi Ray
ff1212e103 images: Ensure that the desired manuals are indeed present
Building an OCI image leads to so much spew that it's hard to notice if
something unexpected happened, and as seen in the previous commit [1],
unexpected things do happen.

Therefore, this adds a built-in test to ensure that the desired files
are actually present in the final image.  Right now it only checks the
presence of some representative manuals to ensure that the packages
listed in the 'missing-docs' file really do get reinstalled, and the
documentation that was stripped out in the base image really does get
restored.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

[1] Commit 1fc50176c9
    https://github.com/containers/toolbox/pull/1226

https://github.com/containers/toolbox/pull/1226
2023-02-01 19:21:59 +01:00
Debarshi Ray
1fc50176c9 images: Avoid unexpected DNF behaviour when reinstalling or swapping
The RPM packages in the base 'fedora' image can be older than the those
currently available in the DNF 'updates' repository [1], but at the same
time newer than those available in the DNF 'fedora' repository [1].  The
first part happens because the base image isn't updated as often as the
individual packages, so the 'updates' repository can have newer RPMs.
The second part happens because the base image does get updated after a
stable Fedora has been released, and hence can have newer RPMs than the
'fedora' repository.

This is complicated by the fact that packages can get pulled directly
from Fedora's Koji build system into the base 'fedora' image before
they make it to one of the well-known repositories like 'fedora' or
'updates' [1].  These packages are marked as having come from the
koji-override-0 repository.

All that combined can lead to unexpected behaviour when DNF is invoked
to reinstall or swap the RPM packages in the base image.  Some examples
below.

The base fedora:36 image contains glibc-minimal-langpack-2.35-20.fc36
that came from koji-override-0, while 'fedora' and 'updates' have
glibc-all-langpacks-2.35-4.fc36 and glibc-all-langpacks-2.35-22.fc36
respectively.  This leads to:
  STEP 8/15: RUN dnf -y swap glibc-minimal-langpack glibc-all-langpacks
  Last metadata expiration check: 0:00:03 ago on Wed Feb  1 12:37:04...
  Dependencies resolved.
  ======================================================================
   Package                   Arch      Version          Repository
  ======================================================================
  Installing:
   glibc-all-langpacks       x86_64    2.35-4.fc36      fedora
  Removing:
   glibc-minimal-langpack    x86_64    2.35-20.fc36     @koji-override-0
  Downgrading:
   glibc                     x86_64    2.35-4.fc36      fedora
   glibc-common              x86_64    2.35-4.fc36      fedora

That's unexpected.  Instead of upgrading all the glibc sub-packages to
the latest version from 'updates', it's downgrading them to the older
version from 'fedora'.

Similarly, the base fedora:36 image has bash-5.2.9-2.fc36.x86_64 from
koji-override-0, and there is bash-5.2.15-1.fc36.x86_64 in 'updates'.
This leads to:
  STEP 10/15: RUN dnf -y reinstall $(<missing-docs)
  Last metadata expiration check: 0:00:06 ago on Wed Feb  1 12:37:04...
  Package acl available, but not installed.
  No match for argument: acl
  Installed package bash-5.2.9-2.fc36.x86_64 (from koji-override-0) not
    available.

That's unexpected.  Instead of upgrading bash to the latest version from
'updates', it's simply skipping the 'reinstall', which means that the
documentation that was stripped out in the base image doesn't get
restored.

Updating all the RPM packages in the base 'fedora' image to match the
contents of the 'updates' repository before making any changes to the
image's package set will avoid such unexpected behaviour.

Only the images for currently maintained Fedoras (ie., 36, 37 and 38)
were updated.

[1] https://docs.fedoraproject.org/en-US/quick-docs/repositories/

https://github.com/containers/toolbox/pull/1226
2023-02-01 19:17:14 +01:00
Debarshi Ray
0fa328dec2 images/fedora/f36: Pull in the i18n and l10n fixes from f37 and f38
This is a combination of the following commits:
  * e6a27d7926
  * f5388cfc06
  * 5b4a4449b0
  * 42dbd8e182

https://github.com/containers/toolbox/issues/60
2023-02-01 01:05:26 +01:00
Jonathan Lebon
1f7b9d0d75 images: add findutils and sudo to missing docs for f36+
Noticed today that `man xargs` was returning the POSIX manpage instead
of the one shipped by `findutils`.

Signed-off-by: Jonathan Lebon <jonathan@jlebon.com>
2022-10-13 07:18:06 -04:00
Nieves Montero
2f7c8586ef Added new packages to images f36 AND f35
The following packages have also been added to images f36 and f35:
mesa-dri-drivers
mesa-vulkan-drivers
vulkan-loader

https://github.com/containers/toolbox/pull/1124
Signed-off-by: Nieves Montero <nmontero@redhat.com>
2022-09-14 07:00:57 -04:00
Timothée Ravier
fd6510c940 images: Make locate(1) opt-in by default
Currently, the entry point of a Toolbox container runs updatedb(8) on
start-up, which can be very I/O intensive. This might be a hindrance
when troubleshooting performance problems on a host, or when
re-creating containers somewhat more frequently.

Users can install the mlocate RPM and restart their containers to
enable locate(1).

Only the images for currently maintained Fedoras (ie., 34, 35 and 36)
were updated.

https://github.com/containers/toolbox/pull/938
2021-12-01 16:21:42 +01:00
Debarshi Ray
cfffb72fb0 images: Remove misleading and redundant CMD
There's no need to specify a CMD in a Toolbox image because it's
specified by 'toolbox create', through 'podman create', when creating a
container.

A CMD was specified [1] because the Fedora Container Guidelines
requires it [2]. The idea behind the guidelines is that the right
thing should happen when one runs:
  $ podman run <image>

However, that only makes sense for images targeting single service
containers. Toolbox containers and images are different - they are not
meant to be used like that to run a single one-off service.

Conceptually, 'running' a Toolbox container is expected to provide the
user with a reasonable interactive command line experience. Arguably,
that means offering something like /bin/bash, not /bin/sh.

Also, note that when the CMD was introduced [1], Toolbox containers
were actually created, through 'podman create', with /bin/sh as their
entry points. So, it did make some sense. However, things have changed
since then [3]. The entry point is now 'toolbox init-container'. It's
not possible to mention it in the Toolbox image because the
/usr/bin/toolbox binary isn't present in the image, and it's not meant
to be present.

Therefore, today, /bin/sh is simply not the right fit for a Toolbox
image's CMD. A better option would be /bin/bash.

Note that the fedora base images have their CMD set to /bin/bash, which
is inherited by the fedora-toolbox images.

So, there are two options. Either repeat the same CMD in the
fedora-toolbox images and satisfy the guidelines, or take some
liberties and let the CMD be inherited from the fedora base images.

This commit takes the latter option. People tend to use the
fedora-toolbox images as the starting point for other custom Toolbox
images, sometimes for other operating system distributions. It's
better to keep them minimal to avoid implying extra requirements. In
this case, the CMD is an abstract concept, and the actual entry point
is 'toolbox init-container' as specified by 'toolbox create'.
Specifying /bin/bash might discourage people from creating custom
images that are only meant to have /bin/zsh.

Also, note that the current CMD was actually '/bin/sh -c /bin/sh', not
/bin/sh. Unless a CMD is specified as an array of command line
arguments, it's passed as a single argument to '/bin/sh -c' [4]. So,
this:
  CMD foo bar

... is the same as:
  CMD [ "/bin/sh", "-c", "foo bar" ]

Only the images for currently maintained Fedoras (ie., 34 and 35) were
updated.

This reverts commit 5cc2678a36.

[1] Commit 5cc2678a36

[2] https://docs.fedoraproject.org/en-US/containers/guidelines/creation/

[3] Commit 8b84b5e460
    https://github.com/containers/toolbox/pull/160

[4] https://docs.docker.com/engine/reference/builder/#cmd

https://github.com/containers/toolbox/issues/885
2021-12-01 01:08:56 +01:00
Debarshi Ray
8071bb5cb8 images: Add fedora-toolbox image definition for Fedora 36
https://github.com/containers/toolbox/pull/931
2021-11-19 03:27:45 +01:00