On Wed, Apr 1, 2015 at 3:40 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
There's some confusion around this, so I thought I would post to
try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
I'm reading it. I'm afraid it's unnecessarily confusing, and there's
already a workable approach with "/etc/alternatives" used for Java and
sendmail equivalents. Why re-invent the wheel?
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
As opposed to providing the binaries or wrappers in an alternative
location, adding /etc/alternatives hooks to link dnf-yum components to
/usr/bin/yum, and putting in .spec staqnzs that says "Provides: yum"
* yum is installed if something that depends on yum pulls it in or
say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
As opposed to alternating the binary installation location and using
/etc/alternatives to link it to /usr/bin/yum.
This approach is old and effective for Java, for /usr/sbin/sendmail,
and for numerous other tools. Why would you want to reinvent the wheel
and prevent people from having either as needed?
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
See above.
* If you are using the yum python bindings directly, that will
continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
kevin
I think that, if you're suggesting the approach, you're trying to
re-invent the same wheel that multiple KDE and Python and Java and
SMTP server have been cycling around on for a long, long time, and
it's a serious tactical error. Don't try to outsmart the user and
decide that the packages must forcibly conflict. Let them have both,
and set the default to something sane.