Details Of DNF Succeeding Yum In Fedora 22 Still Being Discussed

[Candy]

Hello,

I just registered here myself as a new user because this topic caught my attention.

A). DNF is a drop-in replacement for yum, and really yum-ng, and so it should have the name and command interface of yum and they shouldn't be playing around with these kinds of scripts period.

Yesterday after this topic has been brought up on phoronix.com I had a closer look at dnf (now that yum got marked deprecated). After some investigations and experiements I can clearly conclude that dnf is *not* there yet.

Quite an subset of yum commands are missing. For example it is impossible to do:

yum swap -- autoremove <packageset> -- install <packageset>

or

yum --downloadonly --downloaddir=<path> --assumeyes group install "gnome-desktop"

I do not want to explain why I (we) use to do this but all I can say is that there is an operating infrastructure build around yum (written by me (us) which is well documented and is working for quite some time now. I already filled in some bugs in bugzilla.redhat.com:

Some of these bugs (at least one so far) got closed as duplicate. It was commented and pointed to some "other command set" doing something similar (but not equally). The point for me coming here is that from what I heard is, that dnf is an in place replacement of yum. Sadly not providing the *same* command set. Forcing people to rewrite huge chunks of existing 3rd infrastructure because commands have changed, operate differently or simply do not exist.

To be fair, here the reports:

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

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

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

While I was typing this I got a reply on bugzilla saying that dnf is not a drop in replacement of yum.

[Chewi]

Well I switched to dnf a while ago and it's working fine here. I don't care what it's called.

[droidhacker]

I've promised to myself not to answer to this tread anymore but i just can't keep it.
Did you ever tried that routine?

Yes, lots of times.

Keep trying buddy, you're on your own on this one. Just because people faced "rpm dependency hell" in the 90's, before yum was even available to sort that out, doesn't mean that those old problems are still making life miserable.

[droidhacker]

Well, technically you're first supposed to update yum, then kernel, then selinux-policy-targeted, then boot to new kernel and finish the update. Or you can just use fedup. Selinux-policy-targeted is important because otherwise your disk is likely incorrectly labeled after upgrade and you need full relabel which is slow

Actually, you're just supposed to do what the link says. And there is no reason to reboot on a new kernel during a system upgrade.

[droidhacker]

That is not what the script does. It has a message in front saying yum is deprecated but it also automatically redirects to dnf. So it works more like an alias. This maintains backward compatibility for the most part (dnf and yum have *mostly* similar options but it is not 100%) while allowing a transition period. This is pretty similar to how service command in Fedora redirects to systemctl automatically.

Well, the difference here is that systemctl isn't a "drop in" replacement for 'service'. It is something new entirely, and the current 'service' command is a lot more complex than the current 'yum' command, since it has to reformat the input parameters to match systemctl.

[nanonyme]

Actually, you're just supposed to do what the link says. And there is no reason to reboot on a new kernel during a system upgrade.

I'll need to review the fedora-upgrade script when I have time to comment further but it's highly probable that guide will result in an incorrectly labeled disk. I was just discussing about this on #fedora-qa some time ago and lost my illusions about upgrades being easy during it

[Candy]

A couple of hours passed and I end up being totally irritated:

I initially opened two bugs regarding dnf on bugzilla.redhat.com in the hope that the missing features will show up once Fedora 22 arrives.

One has been marked duplicate and redirected to an already closed bugreport. Giving me no chance to explain my use case. Another one has been marked duplicate where my use case was cut entirely out of context. The changes they made in bugzilla regarding my RFE's (or bugs) are dealt with in a way that I end up not really knowing what the current state is. At least it would have been nice to apply the name (or email) to the current active bugreport.

On the fedora-mailinglist they invite people to put requests to bugzilla (which is good) and then the reports end up being closed in such a fast way that you can't really keep track whether your "use case" is still being processed or not. I just wrote a "use case" to an already closed bug not knowing whether it gets received or not.

Marking things as duplicate and pointing them to already closed bugs doesn't help. Looks like there is no real interest in communication.

I don't really know how playing with core packaging tools like yum and delivering dnf (which only has a subset of functions) gonna end. This is nothing against dnf, it's only worrying how I get my own written stuff (around yum) running in the future.

1) This is not how I expected dnf to replace yum - to say the truth.
2) I am not sure whether I want to have all my stuff rewritten once again (if something like this happen again).

[RahulSundaram]

Except that yum's features are a superset of dnf's features so not everything can be redirected. Eg yum's transactional shell is a highly powerful feature through which you could basically do anything else that's missing in dnf if it was implemented. I mean, fine, it's manual repair but it allows people to carve you a manual transaction that will fix your system in a support channel

I am not sure what you are disagreeing with since I already mentioned that dnf and yum is not 100% compatible. You can't really implement anything new in a yum shell. It merely uses existing functionality interactively and doesn't apply to backward compatibility in the context of shell scripts.

[RahulSundaram]

Well, the difference here is that systemctl isn't a "drop in" replacement for 'service'. It is something new entirely, and the current 'service' command is a lot more complex than the current 'yum' command, since it has to reformat the input parameters to match systemctl.

That is a implementation detail. I was just noting that the redirection was inspired by systemctl.

[Luke_Wolf]

That is not what the script does. It has a message in front saying yum is deprecated but it also automatically redirects to dnf. So it works more like an alias. This maintains backward compatibility for the most part (dnf and yum have *mostly* similar options but it is not 100%) while allowing a transition period. This is pretty similar to how service command in Fedora redirects to systemctl automatically.

You could have done the same thing with zypper (extending it to support any missing features), and spared yourselves the time developing DNF. I understood and respected the need for DNF when it was just yum-ng, with DNF being a temporary name for the purposes of having a different binary so that yum and DNF were co-installable while it was being developed, and the plan was to rename it to yum when it was finished. I am sympathetic to the need for backwards compatibility.

This however is not what was sold to us. If you're using a script to create a facade for yum with a deprecation warning (I presume the script will be removed in the future), then there's no reason for DNF to have been created as opposed to just using zypper. Unlike with display servers I'm not particularly against there being a billion different package managers, but ffs don't declare a rationale for creating replacement software and not using an alternative, and then trample all over that rationale.