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? 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
...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
