Yum Won't Be Dropped For Fedora 29

[phoronix]

Phoronix: Yum Won't Be Deprecated For Fedora 29

There had been plans drafted to finish dropping Yum 3 in Fedora now that DNF is quite mature as the next-generation package manager, but that isn't happening now until at least Fedora 30...

http://www.phoronix.com/scan.php?page=news_item&px=Yum-Still-In-For-Fedora-29

[macemoneta]

Yum is just a dnf wrapper at this point in Fedora anyway. It really doesn't matter.

[RahulSundaram]

Yum is just a dnf wrapper at this point in Fedora anyway. It really doesn't matter.

The proposal is not talking about the yum symlink but the original yum which is available in the yum-deprecated package

[r1348]

The proposal is not talking about the yum symlink but the original yum which is available in the yum-deprecated package

Does dnf have feature parity with yum, or is there still something holding porting all infrastructure over dnf (apart from the porting work itself, obviously)?

[RahulSundaram]

Does dnf have feature parity with yum, or is there still something holding porting all infrastructure over dnf (apart from the porting work itself, obviously)?

dnf does have feature parity but the api is different (yum didn't really have a well defined API). Infrastructure pieces are not quick to move over.

[Candy]

dnf does have feature parity [...]

Talking about "feature parity". Where can I find "yumdb" for DNF ? The entire yum-utils port is missing.

[by.peroux]

dnf does have feature parity but the api is different (yum didn't really have a well defined API). Infrastructure pieces are not quick to move over.

Yeah basically makind a microsoft move by keeping compatibility for last decates' bad practice.

[Candy]

Yeah basically makind a microsoft move by keeping compatibility for last decates' bad practice.

The thing here is, that Red Hat allowed "associate developers" with no industry and customer experiences, to fiddle around on an open heart. RPM as well as YUM can be considered "the" core element of the operating system. The package format (rpm) and the package manager (yum).

Wile I do agree that yum needed an overhaul, they otoh changed everything.
- Return values for certain command line operations got changed. So a failure in some cases didn't return a -1 to bash but a 0. Not to mention that scripts that use yum inside were reacting differently because the return values lead further processes within the bash scripts to do something else, that it should have.
- Stuff got removed from dnf (or the fork (in case it's not an entire rewrite)) because the "associated" assumed, that the features were not needed.
- Changes in verbose and debug output.
- Command line arguments that do "similar" things but not the "same", even if the result can be said "they do the same".

For Fedora reasons this approach can be considered as a community project. For RHEL things look differently because companies who have RHEL installed on their computers or on virtual machines may be using yum for various reaons where yum may do things that might not be intended for yum to be done.

I had various RHBZ conversations where I was asked "please tell us more about your use cases" where I had to reply that we can't tell anything about our use cases because this would uncover our business secrets. I was also accused as "troll" once - instantly after they closed various of my bugreports within minutes after posting. Not even going into the issue of the report itself.

That's what happens if you let said "associtate developers" who represent a company reply to "possible" customers or other community members who are also customers. I would have cared less if they did it in their spare time and without the companies email addresses they were using. But getting replied within the work time of the day was quite hard.

Red Hat might be interested to set up some policy for associate employees, so they know howto communicate and represent the company to the outside. Specially during work time and work days. But at the end I blame the project leader, who is in charge of dnf for this to happen.

Currently DNF reached a point of shape where it can be considered "it's working". Still yum-utils is not ported.

From our view and our own yum needs, we had pretty much hard times converting our internal scripts to match whats offered by dnf. We had to change how return values are dealt with, we had to change how we captured verbose output done by yum, we even had our systems stay broken for many weeks because yum wasn't able to deal with rich dependencies that appeared in rpm.

Right now things are working.

Now imagine if RHEL adopts dnf as default... I can assure that there are other companies struggeling as well once they are forced to deal with dnf rather than yum.

So please be cautios whenever saying something like "dnf is yum" or "dnf is on pair with yum" or "the normal user don't care". It's not!

[RahulSundaram]

Talking about "feature parity". Where can I find "yumdb" for DNF ? The entire yum-utils port is missing.

https://github.com/rpm-software-management/libdnf/tree/master/docs/history

https://fedoraproject.org/wiki/Yum_to_DNF_Cheatsheet

Various parts of yum-utils is built-in for dnf including repoquery, downloader etc

[Candy]

Various parts of yum-utils is built-in for dnf including repoquery, downloader etc

I know this. But still: Doing it "similar" is not doing it "same". As mentioned, we had to alter huge chunks of our stuff to match how dnf offered it. But still yumdb is missing.

So please stop advocating DNF as the optimal solution. I remember one of your RHBZ bugreports where you raised the point that switching from yum to dnf will make lots of scripts break.

I don't want to be the guy who one day says "we don't need sed and grep anymore because the normal users don't know them or don't care". Millions of scripts broken, because one single person decided how other people should deal with their system. The same applies for yum vs dnf. yum is too important and too much tied into the core system. So it can not be replaced by something totally different. Not until the replacement offers the same features as the thing that should be replaced.

Reapeating how gread DNF is, simply makes it not getting more true.

Imagine the following situation:

RHEL and EPEL products being used in a company environment. Scripts have been written, tested, documented and maintained for years. Customer paid for it or the scripts got paid because and internal account or project number has been made available for the developer to develop the scripts.

Now DNF shows up and you end up in plenty of broken scripts.

What do you tell your customers ?

"Yes! DNF is feature pair with YUM!" or "Well you need to change the command lines because things are done differently now!"

And I as project leader ask mysekf:
- Who does the change for the code ?
- Who does the change for the documents to explain the changes ?
- Who is auditing the people in the company who needs to deal with that ?
- WHO THE F*<word> is going to pay for this ?

This all doesn't include other areas that are not covered. Like what does DNF return (as return value) in case it fails ? Does it return -1 in this segment of our code, so it goes into workflow (a) or into workflow (b). No DNF returns 0 now, so it by mistake jumps into workflow (b), while it should have jumped into workflow (a) of our scripts. Causing a lot of administrative work to a sequence, that initially ran automatically because we used yum (for years).

I hope I was able to make myself understandable...