#1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Closed None Opened 9 years ago by jreznik.

This is F22 Change Proposal!

For the 2014-06-18 meeting as the Change Proposal was announced on devel-announce list on 2014-06-11.

Make DNF/Yum4 the new default packaging tool in F22.


I think the command should still be called "yum", and the old command be renamed to "yum-legacy".

There was considerable support for this in the mailing list discussion.

I expressed the same idea earlier in the fedora devel mailing list as well. dnf started off as a fork of yum and can be treated as a new major version of yum with a significant rewrite of the codebase along with API changes and some command line options and does not warrant changing the name of the command itself. please don't change the command name and create unnecessary burden for admins who have to deal with multiple versions of the OS.

Some concern was raised on the fedorda-devel mail list about the fact that unlike yum dnf by design lacks some protection measures against user errors:

https://lists.fedoraproject.org/pipermail/devel/2014-June/200252.html

The discussion on the mail list did not reach a conclusion, so I think (from my user perspective) the matter may require some FESCO attention.

Well, it sort of did:

https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c29

https://bugzilla.redhat.com/show_bug.cgi?id=1111855

dnf maintainers are going to implement a plugin. Of course some could consider the implementation not enough, but it's hard to say before it's even been implemented.

At the meeting 2 weeks ago:

AGREED: Fedora 22 will use DNF by default, details will be worked out as we go (+7, 0, -0)

If you still have concerns about the approach to protecting package removals, can you file a new ticket on that? Thanks.

Cloud WG would like some guidance about some of the details we left to be worked out. Specifically, in F22, should we include yum and/or dnf-yum? What are the other variants (both server/workstation and spins) doing, or should be doing? Is this an area where we want consistency?

IMHO (speaking for myself, but perhaps the rest of FESCo agrees):

  • You should not be explicitly installing yum in f22, but if it's pulled in by some dependency then it is, and thats fine.

  • You should not be installing yum-dnf.

Ideally in the f23 timeframe we can fix the remaining items that depend on yum and then it will just not get pulled into any images. IMHO, we should never install yum-dnf, as yum and dnf behave differently enough that we shouldn't surprise people using yum by changing that to dnf.

+1 to what Kevin said above.

Replying to [comment:7 kevin]:

IMHO (speaking for myself, but perhaps the rest of FESCo agrees):

  • You should not be explicitly installing yum in f22, but if it's pulled in by some dependency then it is, and thats fine.

  • You should not be installing yum-dnf.

I agree with this. IMHO this is also what was the outcome of the last FESCo discussion on this topic. IOW not to install dnf-yum in F22 by default.

Yes, I'm also +1 to everything that Kevin said above.

ok, so thats +5 for that, so it passes?

mattdm: Does that answer your concerns, or did you need further discussion in meeting.

If so, please reopen and/or bring up at tomorrow's meeting.

Well, I'm not really happy with it. I really would like to minimize change pain for Fedora users, and it seems like a relatively small investment into user experience would go a long way to making that better. I want to be able to tell people with a straight face that Fedora is for users, not just people developing an operating system.

Plus, it will require basically all documentation to be changed, not just ours, but every guide about installing software on Fedora ever. That's not a small cost either.

I know that the commands and behavior are not exactly the same, but they should be fundamentally the same for the most important operations -- and if they're not, we really should look at delaying the switch until it's ready. Things like "deps might be solved differently" are small pain, but are also the kind of thing people might reasonably expect with a change from one major yum release to the next.

It doesn't really matter what the underlying package is called, but I really think we should at the very least keep "yum" as the main command line tool, and keep that as the main thing we use in all user-facing documentation.

As Richard notes in the first comment above, there was considerable support for this position in the devel-list discussion. I don't think really anything has changed since that time -- except that dnf has become more compatible.

Replying to [comment:13 mattdm]:

I agree with Matt that once we really do the switch to DNF (not just don't install yum by default, we should install the dnf-yum package. For F22 it is already decided, but I'm in favor of installing dnf-yum in later releases.

There are differences, sure. But as said, the basics are consistent with YUM. The documentation rewriting is a valid point. Also users installing latest Fedora after years will most probably look for yum, not dnf. Also people may have scripts calling yum. I think we should really provide the command as an alias to DNF, most probably from F23.

It seems to me there's (at least) two cases of things that use yum:

  1. It's a script or thing that just calls /usr/bin/yum command line and does something. This sort of thing would likely be ok if we installed dnf-yum. Or might only need some minor tweaking.

  2. Its a script or thing that does 'import yum' and uses a yum object. This sort of thing would be completely broken by installing dnf-yum.

Perhaps there's some middle ground here where we change yum to provide say /usr/bin/yum-depreciated but all it's normal python files, and install dnf-yum to be /usr/bin/yum (ie, make them not conflict). Then folks that need to port to the dnf api can still function and command line folks and docs can stay the same and people who really really want to use the yum command line can still get it until the day it's finally retired.

If (2) is the worry there is an easy answer: put the major version number into the library name. So you have import yum4 for the new library and import yum for the legacy api. I know this sort of forethought in versioning incompatible python libraries would have made other upgrades easier. Packages for both libraries would need to remain in the distribution for this strategy to work.

Replying to [comment:18 toshio]:

If (2) is the worry there is an easy answer: put the major version number into the library name. So you have import yum4 for the new library and import yum for the legacy api. I know this sort of forethought in versioning incompatible python libraries would have made other upgrades easier. Packages for both libraries would need to remain in the distribution for this strategy to work.

I'm not sure I follow.

Right now dnf uses a "dnf" object and you import dnf.
Yum uses a yum object and you import yum.

Are you suggesting that yum keep using yum and dnf uses 'yum4' ? Not sure how thats better than just changing to 'dnf' ?

The library could stay dnf with the same advantages as using yum4. However if the command-line name changes to yum its probably suboptimal that the library implementing it remains named dnf. That will be another point of confusion, I think: "I want to use the yum api so I type 'import dnf'? What?" Using yum4 for the library name would be better. (That leads, however, to even more api changes: if there's objects and functions in the library with dnf in the name then those should change to yum as well.)

So more work for dnf developers being traded for increased consistency for people who are using the api.

Yeah, I think the only way that would have worked well is if the dnf folks when they started just called it 'yum4' instead. Sadly, I think that ship has sailed.

We have things using the dnf api now (anaconda and lorax at least).

So, the best thing we can do here IMHO is replace the command line (which behaves very similarly), and leave the bindings alone. I'll shut up now however and let other interested parties chime in. ;)

Replying to [comment:21 kevin]:

So, the best thing we can do here IMHO is replace the command line (which behaves very similarly), and leave the bindings alone. I'll shut up now however and let other interested parties chime in. ;)

Right, so, this would become "Yum, now powered by DNF!", which is a nicer narrative for me to sell.

Replying to [comment:22 mattdm]:

Replying to [comment:21 kevin]:

So, the best thing we can do here IMHO is replace the command line (which behaves very similarly), and leave the bindings alone. I'll shut up now however and let other interested parties chime in. ;)

Right, so, this would become "Yum, now powered by DNF!", which is a nicer narrative for me to sell.

Until people start filing bugs for behavior differences which the DNF developers are aware of and have no intention of fixing.

I understand the argument for making this an easier transition, but covering up the fact that DNF and yum are different things is telling a small white lie that people are going to be bitten by.

I've used dnf almost exclusively for a year or so now, and I think it's fair to say that the behavior differences are either already well documented or corner cases, and generally I haven't seen much where the DNF developers "have no intention of fxing things" — to the contrary, they're generally good about providing solutions to use cases when the use case is understood and thought through.

http://dnf.readthedocs.org/en/latest/cli_vs_yum.html

The above is exactly what I'm talking about. Those are the documented differences that they do not intend to change. For the normal 'yum update; reboot' case, sure it's fine. But that list is not just a bunch of stuff that people don't use.

If we were changing the package manager every other year, I would totally agree with you. However, we are not. DNF is the proposed way forward for Fedora and we might as well make the full transition at the earliest possible time.

For the record, I support Matt's message "yum is now powered by dnf" and there is one simple reason why: imagine a user that doesn't closely follow the Fedora development. He installs F22. Oh wait, there is no yum? How do I install stuff ... ok, let's search the web what's going on and maybe file a bug report that yum is missing in Fedora. The impact in this case is IMO much more severe than users finding small differences between dnf and yum (which are by the way excellently documented).

Having a wrapper script that will clearly tell the user what's happening (like service does) will solve the issue for these users. Moreover, the message indicating that all of the yum functionality is now covered by a different tool will tell people that there is some tool they can use to do whatever they wanted, it works almost the same but there might be some differences.

The service example I was referring to above:

{{{
$ service dbus status

Redirecting to /bin/systemctl status dbus.service
}}}

Replying to [comment:17 kevin]:

Perhaps there's some middle ground here where we change yum to provide say /usr/bin/yum-depreciated but all it's normal python files, and install dnf-yum to be /usr/bin/yum (ie, make them not conflict). Then folks that need to port to the dnf api can still function and command line folks and docs can stay the same and people who really really want to use the yum command line can still get it until the day it's finally retired.

This is a great solution; having some F22 installs that have ''nothing'' at /usr/bin/yum is a really bad migration experience (and “Oh something will be there in F23” does not help at all).

OTOH it is after Alpha; are we (and more to the point, the relevant expert maintainers) comfortable enough with doing this?

I talked to yum maintainer and we will go with the solution from comment 28. To recap plan for F22+:
dnf-yum will be installed by default (needs to be added to comps)
dnf-yum will not confict with yum package
/usr/bin/yum binary from yum package will be renamed to /usr/bin/yum-depreciated
/usr/bin/yum-depreciated will print warning message after execution: "yum is obsoleted, use dnf instead" and will run yum from cmdline interface afterwards
/usr/bin/yum from dnf-yum package will print warning message after execution: "redirecting to dnf" and then will execute /usr/bin/dnf
dnf and yum python API will remain the same

Any objections?

if I have some scripts or applications that are calling binary /usr/bin/yum then how will they work after implementing above solution? I guess all such calls to /usr/bin/yum need to be renamed to /usr/bin/yum-depreciated then?

Replying to [comment:30 pnemade]:

if I have some scripts or applications that are calling binary /usr/bin/yum then how will they work after implementing above solution? I guess all such calls to /usr/bin/yum need to be renamed to /usr/bin/yum-depreciated then?

They should be checked, but many of them will just work, just fine with no changes.

One tiny note: you should use yum-deprecated rather than yum-depreciated. Depreciated has a related but different meaning.

Replying to [comment:32 toshio]:

One tiny note: you should use yum-deprecated rather than yum-depreciated. Depreciated has a related but different meaning.

Heh. Indeed.

Speaking for Red Hat, I'd prefer leaving "yum" as the command with "powered by dnf". And renaming the existing yum as yum-deprecated seems appropriate. That helps make it clear that there is a mostly-compatible but new-and-improved replacement. And it saves a lot of effort in converting doc, rewriting scripts, and retraining muscle memory.

Let's have a discussion followed by voting on the proposal (https://fedorahosted.org/fesco/ticket/1312#comment:29) by dnf developer in the coming meeting.

From today's meeting,
* AGREED: Replace Yum with DNF in F22+ with plan given in https://fedorahosted.org/fesco/ticket/1312#comment:29 but complete it before beta freeze

jsilhan, can you please implement your plan before F22 beta freeze?

Thanks.

I really think "/usr/bin/yum from dnf-yum package will print warning message after execution: "redirecting to dnf" and then will execute /usr/bin/dnf" needs to be revaluated, I think it should not print and redirect it should just run the task. i think we should do the opposite and have /usr/bin/dnf say redirecting to yum

Replying to [comment:37 ausil]:

I really think "/usr/bin/yum from dnf-yum package will print warning message after execution: "redirecting to dnf" and then will execute /usr/bin/dnf" needs to be revaluated, I think it should not print and redirect it should just run the task. i think we should do the opposite and have /usr/bin/dnf say redirecting to yum

Can you please share some reasons/use-cases why this should be done as you are proposing? Thanks.

Replying to [comment:36 pnemade]:

jsilhan, can you please implement your plan before F22 beta freeze?

Sure.

Replying to [comment:38 thozza]:

Replying to [comment:37 ausil]:

I really think "/usr/bin/yum from dnf-yum package will print warning message after execution: "redirecting to dnf" and then will execute /usr/bin/dnf" needs to be revaluated, I think it should not print and redirect it should just run the task. i think we should do the opposite and have /usr/bin/dnf say redirecting to yum

Can you please share some reasons/use-cases why this should be done as you are proposing? Thanks.

From a strictly user perspective (and therefore, also including user documentation), this is a clear ideal. Warning messages only appear when there's a possibility of a compatibility difference causing drastically different behavior, and we phase out those warnings over time. That way, the user is exposed to necessary change, but not repeatedly poked with "the thing you're doing is wrong!" due to a distribution change they didn't ask for (and where the benefits are real but generally abstracted from user experience).

Replying to [comment:38 thozza]:

Replying to [comment:37 ausil]:

I really think "/usr/bin/yum from dnf-yum package will print warning message after execution: "redirecting to dnf" and then will execute /usr/bin/dnf" needs to be revaluated, I think it should not print and redirect it should just run the task. i think we should do the opposite and have /usr/bin/dnf say redirecting to yum

Can you please share some reasons/use-cases why this should be done as you are proposing? Thanks.

Comment 34 also "Yum, now powered by dnf" doesn't make much sense when you then say actually go use dnf. end user and documentation either needs changed or not, by saying that you should use dnf you will confuse users. it also makes no sense to rename the yum command without renaming the dnf command. I honestly do not see a point in time in the future where we can remove the yum command. as the end user docs and experience issues will not go away. therefore the only viable option is to keep the command name yum. we can keep the library dnf, since yum is now powered by dnf.

Documentation for two different sets of /usr/bin/yum behavior is going to be more confusing than learning a new command. Users are going to expect yum behavior from /usr/bin/yum, and dnf doesn't behave like yum in all ways. There will be some users whose yum behaves like dnf, some whose yum behaves like yum, and while we can update the Fedora documentation, we can't predict what behavior any third party stuff will refer to.

It seems saner and more honest to me for the user to be confronted with the change upfront with a "you are actually using dnf" redirect warning - and tbh, I'm not a fan of dnf-yum for similar reasons - than to have the sour experience of a series of yum invocations working predictably and then suddenly not when the user encounters a differing behavior. I don't believe that the overall experience is improved by obscuring this change.

This seems like an award-winningly, spectacularly bad idea to implement at this point in the release cycle (or, arguably, at all), and QA was not at all aware of it and has drawn up no plans to test it. We have been working on the belief that dnf was no longer expected to literally replace yum as their behaviours are known to be substantially different.

I personally expect this change will be found to cause major, multiple problems, and think it's a really bad idea and we shouldn't do it at all. But at a minimum, doing it now for F22 seems inarguably a terrible idea.

immanetize , it's my sense that the vast, vast majority of documentation (both third party and our own) will simply refer to "yum install" and "yum remove", which should be functionally similar for the required purpose. (The details, like different depsolving, have already changed significantly over the course of yum's lifetime without the command changing.)

But, I think I've already made my opinion known overall so I won't harp on it more and will do my best to support whatever decision y'all come up with here.

Login to comment on this ticket.

Metadata