----- Original Message -----
From: "Przemek Klosowski"
<przemek.klosowski(a)nist.gov>
To: devel(a)lists.fedoraproject.org
Sent: Thursday, April 9, 2015 5:01:19 PM
Subject: Re: dnf replacing yum and dnf-yum
On 04/08/2015 02:32 AM, Jan Zelený wrote
> I'm afraid not. From the very beginning, we were sending a
clear message
> that
> we will be as compatible as possible in terms of CLI but we never wanted to
> have just another yum. If that was the case, we wouldn't call the project
> differently.
I am concerned that the yum-to-dnf transition is confusing, because
of this
mixed message. On one hand, they are just two package management tools: on a
high level, they do a simple, well defined job of updating your system to
the latest version of available packages. In an ideal world it just wouldn't
matter which one you use, and from that point of view the name change is
superfluous: all you need to do is 'yum update', and calling it 'dnf
update'
is just a tiny annoyance that is not bothersome enough to be worth bothering
about.
We are not living in an ideal world, however, and the updating
problem is
complex enough so that yum ecosystem is not handling it well. You are making
an argument that dnf reimplemented this ecosystem in a qualitatively
different, more correct way, that is so different that it merits a clean
break, justifying the project name change. I am fine with that, but this
leads to confusion when there are observable changes in behavior. The
implication is that dnf is better and more correct, but on the other hand
it's clear that dnf is still in development and exhibits faults. So, now we
have a problem: if dnf behaves differently from yum, is it an improvement or
a regression? We don't know, and it's not clear to me how to tell; every
divergence is a potential bug in dnf, and therefore should be reported as
such.
I would venture a comment that it was a mistake to declare dnf a
separate
project, because it leads to a different approach to such differences. If it
was an evolutionary change in yum, it would be natural to expect it to
behave in a compatible way, and consequently detect and explain in more
detail the divergent behavior. By declaring a clean break, you are basically
saying that there is no need to explain the diffs, but the flip side of it
is that unless I can clearly understand why the difference is for the
better, I must suspect this to be a regression and report it.
As a result, dnf will have a huge bug load that is hard to work with
because
it depends on a specific state of the repositories at that specific moment
in time. Do you have a capability to investigate such problems?
Yes, we have.
"dnf --debugsolver" helps us a lot.
Here's a specific one, a firefox update from this morning that
shows up in
yum but not in dnf. I will submit it to bugzilla, just to see where we go
with that.
# dnf update firefox
Using metadata from Fri Apr 3 03:24:08 2015
Dependencies resolved.
Nothing to do.
# yum update firefox
Loaded plugins: auto-update-debuginfo, langpacks
Resolving Dependencies
--> Running transaction check
---> Package firefox.x86_64 0:37.0-2.fc21 will be updated
---> Package firefox.x86_64 0:37.0.1-1.fc21 will be an update
--> Finished Dependency Resolution
# dnf info firefox
Using metadata from Fri Apr 3 03:24:08 2015
Installed Packages
Name : firefox
Arch : x86_64
Epoch : 0
Version : 37.0
Release : 2.fc21
...
# yum info firefox
Loaded plugins: auto-update-debuginfo, langpacks
Installed Packages
Name : firefox
Arch : x86_64
Version : 37.0
Release : 2.fc21
...
Available Packages
Name : firefox
Arch : x86_64
Version : 37.0.1
Release : 1.fc21
Size : 69 M
Repo : updates/21/x86_64
...
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech