Bug 1313912

Does dnf or zypper support the same options an same error codes? or is this benefit relatively limited?

(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.

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?

(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.

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?

(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.

closing as a different solution has been agreed upon.

What's the different solution?  Can you link to it?

(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.)