Bug 1313912 - Add ENV variable 'PKGM' to base image
Add ENV variable 'PKGM' to base image
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-server-docker (Show other bugs)
7.3
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Frantisek Kluknavsky
atomic-bugs@redhat.com
:
Depends On:
Blocks: 1313920
  Show dependency treegraph
 
Reported: 2016-03-02 10:26 EST by Brent Baude
Modified: 2016-05-04 11:41 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1313920 (view as bug list)
Environment:
Last Closed: 2016-05-04 10:55:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brent Baude 2016-03-02 10:26:17 EST
For the rhel-server-docker base image, please add the following environment variable to the dockerfile.

ENV PKGM yum

Defining this environment variable and setting the value to 'yum' will allow for greater cross-distribution capability of Dockerfiles between CentOS, Fedora, and RHEL.  Because that environment variable is inherited, users will then be able to do things like this in their Dockerfiles:

${PKGM} -y install <packages> && ${PKGM} clean all

When implemented, this will be defined in the Container-Best-Practices guide project (https://github.com/projectatomic/container-best-practices).
Comment 2 Subhendu Ghosh 2016-03-03 19:55:30 EST
Does dnf or zypper support the same options an same error codes? or is this benefit relatively limited?
Comment 3 Stephen Tweedie 2016-03-04 09:45:18 EST
(In reply to Subhendu Ghosh from comment #2)
> Does dnf or zypper support the same options an same error codes? or is this
> benefit relatively limited?

dnf at least has many of the same options, and can translate many of the ones which are different.

But it can only do needed translation if it knows that that translation is needed --- which it can more easily do if it is invoked as /usr/bin/yum.

It may be that the better solution is to include the dnf-yum translation wrapper in the base image directly: it's literally no more than a 4-line shell script, of which two lines are just the warning that yum is deprecated.  

So if we can support that wrapper, and remove the warning, then we'd be able to do this translation in the most natural place and preserve compatibility across yum/dnf distros automatically.

Adding the packaging team lead to CC:, so they can reply directly.
Comment 4 Frantisek Kluknavsky 2016-03-04 10:02:06 EST
Stephen, does it mean adding dnf-yum wrapper into fedora image and no change at all in the rhel image? Do I understand you correctly?
Comment 5 Stephen Tweedie 2016-03-04 10:06:30 EST
(In reply to Frantisek Kluknavsky from comment #4)
> Stephen, does it mean adding dnf-yum wrapper into fedora image and no change
> at all in the rhel image? Do I understand you correctly?

That would depend on the packaging team's recommendation about whether they will support dnf-yum for the foreseeable future.

If they do, then yes, we'd add dnf-yum to the Fedora image today, and we'd plan on doing so in the future for RHEL once that branches off a dnf-based Fedora; and we'd document that /usr/bin/yum remains the most portable way to define Dockerfiles which are portable across the various Fedora-based distros.
Comment 8 Honza Silhan 2016-03-04 14:40:03 EST
ENV variable could be useful for conditions in corner cases. It should not harm if it's used in `if` statements but not as solution to do transactions "cross package manager way".

We plan to have in dnf-yum compatibility package around 3 easy detected translations from yum to dnf so it's better to have this then plain symlink. Thus it will never be 100% compatible. The way to eliminate nuances is to have in Container best practices guide documented the switches and parameter where it behaves more or less the same (specify the legit package name without glob expressions, use config options that are in DNF, ...)

(In reply to Stephen Tweedie from comment #5)
> ... we'd document that /usr/bin/yum remains the most portable way to
> define Dockerfiles which are portable across the various Fedora-based
> distros.

Simplest would probably be to go with dnf-yum package in Fedora image although I see it as a way backwards WRT transition from yum to DNF globally. I would personally do it other way round to have a /usr/bin/dnf -> /urs/bin/yum symlink in RHEL and CentOS images. Theoretical question: how hard would it be for DNF name to be adopted in RHEL and CentOS Docker ecosystem now?
Comment 9 Stephen Tweedie 2016-03-07 08:07:25 EST
(In reply to Jan Silhan from comment #8)
> We plan to have in dnf-yum compatibility package around 3 easy detected
> translations from yum to dnf so it's better to have this then plain symlink.
> Thus it will never be 100% compatible.
...
> Simplest would probably be to go with dnf-yum package in Fedora image
> although I see it as a way backwards WRT transition from yum to DNF
> globally.

Agreed --- but I think this is fine for now.  We should not aim for 100% compatibility: it's enough for the 99% case (yum update and yum install) to work both with yum and dnf-yum.

It would be much better to simply document that advanced cases will want to invoke dnf or yum directly, than to try for complete compatibility of every possible combination of options.

> I would personally do it other way round to have a /usr/bin/dnf ->
> /urs/bin/yum symlink in RHEL and CentOS images. Theoretical question: how
> hard would it be for DNF name to be adopted in RHEL and CentOS Docker
> ecosystem now?

There are a lot of assumptions built around yum --- there's testing, there are container plugins like subscription-manager and overlayfs, and there is default configuration for minimising locales and docs in container images.  I wouldn't want to have to restart that from scratch for dnf within an existing RHEL major release, nor to have to support both in parallel.
Comment 13 Brent Baude 2016-05-04 10:55:15 EDT
closing as a different solution has been agreed upon.
Comment 14 Colin Walters 2016-05-04 11:05:52 EDT
What's the different solution?  Can you link to it?
Comment 16 Stephen Tweedie 2016-05-04 11:41:49 EDT
(In reply to Colin Walters from comment #14)
> What's the different solution?  Can you link to it?

Basically un-deprecating /usr/bin/yum, and positioning that as the portable CLI for compatibility across different releases with the basic functionalty; and dnf as the CLI for newer releases offering additional functionality (weak/rich deps, modularity work etc.)

Packaging team will be bringing this up on fedora lists, it's highly relevant upstream (eg. for compatibility for Dockerfiles over centos/fedora.)

Note You need to log in before you can comment on or make changes to this bug.