F22 System Wide Change: Replace Yum With DNF
cra at WPI.EDU
Thu Jun 12 14:09:13 UTC 2014
On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote:
> > > We are open to ideas. I think in this situation there is no perfect way
> > > how to satisfy everyone. We have thought about this for several months.
> > > Renaming dnf back to yum might seem like the best option at first (it was
> > > our original plan too) but when you carefully and deeply think about
> > > this, keeping dnf and yum separate is really the least painful choice. So
> > > far I haven't seen a single strong argument against it that would satisfy
> > > needs of all the involved stakeholders.
> > Well having user that upgrade have a different package manager then
> > those who install new is not only "not perfect" but a no go.
> > Simple obsolete yum so that dnf gets pulled in on upgrades and have
> > rename the yum package to yum-legacy or something and have users that
> > want it for whatever reason install it by hand.
> I think this is is alignment with what I said before - yum and dnf will still
> stay separated and dnf is not renamed. So if there is no argument against your
> proposal, we might as well give it a shot.
The arguments against renaming the command have been given. The dnf
command should either be renamed back to yum, or there should be
permanent backwards compatibility via a script, symlink, etc. There
is NO good reason to force everyone to change scripts and command line
habits just for the sake of changing the name of a command that is an
almost 100% compatible evolution of the older command. Call the
package dnf and obsolete the yum package, rename the old yum package
to yum-legacy--fine. But please make "yum install" etc. still work
And if those arguments aren't convincing enough, the second best
option, if you MUST change the name of the command, is to change it
ONCE to something PERMANENT that never changes ever again. Something
generic like "package-manager" or "pkgman". A name like "dnf" isn't
really helpful as part of the system command language "API". It is
obscure lore that contributes to making Linux harder to learn. (So is
"yum" but that ship has sailed.)
More information about the devel