Bug 1806044
Summary: | 'yum -y install buildah fuse-overlayfs --exclude container-selinux' throws error | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Dennis Kliban <dkliban> |
Component: | buildah | Assignee: | Jindrich Novy <jnovy> |
Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> |
Severity: | unspecified | Docs Contact: | Gabriela Nečasová <gnecasov> |
Priority: | unspecified | ||
Version: | 8.2 | CC: | ajia, baptiste.agasse, bmbouter, bmclaugh, ddarrah, dwalsh, gnecasov, james.antill, jnovy, jwboyer, lsm5, pasik, tsweeney |
Target Milestone: | rc | ||
Target Release: | 8.2 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | container-tools-rhel8-8020120200501055448.ffd2803a | Doc Type: | Enhancement |
Doc Text: |
.Installing Podman does not require `container-selinux`
With this enhancement, the installation of the `container-selinux` package is now optional during the container build.
As a result, Podman has fewer dependencies on other packages.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-07-21 15:31:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dennis Kliban
2020-02-21 21:17:13 UTC
I believe the error you're getting is expected. buildah *requires* container-selinux on RHEL 8: $ dnf repoquery --requires buildah ... container-selinux ... That's why when you exclude container-selinux, buildah is no longer installable due to broken deps. Lokesh Mandvekar, is this expected behavior for EL8? (In reply to Dennis Kliban from comment #2) > Lokesh Mandvekar, is this expected behavior for EL8? Jindrich owns the RHEL packages now, he'll check it out.. Looking at Fedora buildah I see these deps are relaxed: Recommends: container-selinux Recommends: slirp4netns >= 0.3-0 Recommends: fuse-overlayfs while in RHEL there are hard dependencies: Requires: container-selinux Requires: slirp4netns >= 0.4.0-1 Requires: fuse-overlayfs Requires: libvarlink I lean for at least container-selinux and libvarlink being soft dependencies. As I see no reason why they should be hard deps. Same applies for fuse-overlayfs if we want to have rootless support optional which I don't think is a good idea. Dan, do you agree? I downloaded and used the scratch build yesterday and ran into the following error during installation: tldr; - package runc-1.0.0-64.rc9.module_el8.1.0+272+3e64ee36.x86_64 requires container-selinux >= 2:2.2-2, but none of the providers can be installed ----- Step 7/24 : RUN dnf -y install /tmp/buildah-1.11.6-8.el8.x86_64.rpm --exclude container-selinux ---> Running in b10fe43e17a1 Failed to set locale, defaulting to C.UTF-8 CentOS-8 - AppStream 1.0 MB/s | 6.5 MB 00:06 CentOS-8 - Base 2.8 MB/s | 5.0 MB 00:01 CentOS-8 - Extras 4.3 kB/s | 2.1 kB 00:00 Error: Problem: package buildah-1.11.6-8.el8.x86_64 requires runc >= 1.0.0-26, but none of the providers can be installed - package runc-1.0.0-64.rc9.module_el8.1.0+272+3e64ee36.x86_64 requires container-selinux >= 2:2.2-2, but none of the providers can be installed - conflicting requests - package container-selinux-2:2.107-2.module_el8.1.0+237+63e26edc.noarch is excluded - package container-selinux-2:2.124.0-1.module_el8.1.0+272+3e64ee36.noarch is excluded - package container-selinux-2:2.94-1.git1e99f1d.module_el8.1.0+236+34fc7673.noarch is excluded - package runc-1.0.0-55.rc5.dev.git2abd837.module_el8.1.0+236+34fc7673.x86_64 is excluded - package runc-1.0.0-60.rc8.module_el8.1.0+237+63e26edc.x86_64 is excluded (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ERROR: Service 'pulp-api' failed to build: The command '/bin/sh -c dnf -y install /tmp/buildah-1.11.6-8.el8.x86_64.rpm --exclude container-selinux' returned a non-zero code: 1 It looks like runc should stop having a hard requirement on container-selinux. Could we get a scratch build of runc without that dependency? I see this in the spec file: * Wed Oct 25 2017 Dan Walsh <dwalsh> - 1.0.0-17.rc4.gitaea4f21 - Add container-selinux prerequires to make sure runc is labeled correctly Is that needed or I can remove the container-selinux from Requires? It should be Recommended not Required. But for runc, it should probably be removed altogether as long as podman, buildah, cri-o recommend container-selinux. There is no hard requirement on container-selinux for buildah-1.14.8-2.module+el8.2.1+6462+4149b287 and runc-1.0.0-66.rc10.module+el8.2.1+6462+4149b287. [root@kvm-06-guest04 ~]# rpm -qR runc-1.0.0-66.rc10.module+el8.2.1+6462+4149b287.x86_64.rpm criu libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.7)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libseccomp.so.2()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) [root@kvm-06-guest04 ~]# rpm -qR buildah-1.14.8-2.module+el8.2.1+6462+4149b287.x86_64.rpm containers-common libassuan.so.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libdevmapper.so.1.02()(64bit) libdevmapper.so.1.02(Base)(64bit) libdevmapper.so.1.02(DM_1_02_97)(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libgpg-error.so.0()(64bit) libgpgme.so.11()(64bit) libgpgme.so.11(GPGME_1.0)(64bit) libgpgme.so.11(GPGME_1.1)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libseccomp.so.2()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) runc >= 1.0.0-26 slirp4netns >= 0.3-0 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3053 |