Details Of DNF Succeeding Yum In Fedora 22 Still Being Discussed

[RahulSundaram]

You could have done the same thing with zypper (extending it to support any missing features

Zypper is just a command line over the library libsolv and that has been extended during the process of developing dnf and is used by it. So yeah pretty much what you described under the hood.

[Luke_Wolf]

Zypper is just a command line over the library libsolv and that has been extended during the process of developing dnf and is used by it. So yeah pretty much what you described under the hood.

No. Zypper is a command line over libzypp, libsolv is the dependency solver that libzypp uses.

[RahulSundaram]

No. Zypper is a command line over libzypp, libsolv is the dependency solver that libzypp uses.

libzypp is merely a convenience library. dnf and PackageKit backend that uses libsolv has one as well but the point is that the core library that does dependency solving is shared between dnf and zypper.

[Luke_Wolf]

libzypp is merely a convenience library. dnf and PackageKit backend that uses libsolv has one as well but the point is that the core library that does dependency solving is shared between dnf and zypper.

And was it really worth it to spend 2 years writing Hawkey and DNF when it turned out you needed to write a yum compat facade on top of it anyway? Frankly, I would call that a failure, unless your desires were actually "We want a python version that better resembles yum than zypper does" which would be a perfectly valid reason but that's not the reason being claimed as that's not the same thing as "Backwards Compatibility" which you have failed at achieving as shown by the need for the facade.

All I'm asking is consistency between word and action.

[RahulSundaram]

And was it really worth it to spend 2 years writing Hawkey and DNF when it turned out you needed to write a yum compat facade on top of it anyway? Frankly, I would call that a failure, unless your desires were actually "We want a python version that better resembles yum than zypper does" which would be a perfectly valid reason but that's not the reason being claimed as that's not the same thing as "Backwards Compatibility" which you have failed at achieving as shown by the need for the facade.

All I'm asking is consistency between word and action.

Let's get something straight. I am not involved with dnf development and would prefer to just continue using yum as the command line.

Having said that, backward compatibility isn't limited to the command line. Speaking to your point, it involves working with tools that use Python extensively including Koji, Mock, Anaconda etc. This isn't a new thing

http://fedoraproject.org/wiki/Features/DNF

"Hawkey clients will get:

• easier bindings to other languages than Python"

A major portion of the time spent on this is coordinating development and integration with a large number of tools. Not just dnf itself. Was it worth it? dnf developers obviously thought so and Fedora has accepted that rationale. You are free to disagree but calling it a facade is going too far.

[gilboa]

It is 2015 and for all rpm based distributions it is still problem to upgrade from one release to next one without some magic!
It is obvious package type problem if no one can achieve it.
It is easy to write package manager for dpkg this is why there is so many of them and only two for rpm.

And it is very ugly when under your name is written for whom you work and to start talk about other distributions. this seems to be your company PR problem

I manage >50 (closing on 100) different Fedora machines ranging down from low-end VMs and low-end netbooks up to high-end Xeon workstation and servers.
I upgrade them from one version to another using fedup.
Upgrading Fedora 20 to 21 simply worked. Period.

Care to backup your statement with actual numbers?