F22 System Wide Change: Replace Yum With DNF

[Nico Kadel-Garcia]

On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson
<bjorn at xn--rombobjrn-67a.se> wrote:
> Please keep the command name "yum", and keep the command line syntax
> and the configuration language as compatible as is feasible. Make a
> wrapper or a symlink if you need to, but plan to keep it forever, not
> just for a year or two.

The name change is gong to break every 'chef' cookbook that uses the
'yum_package' utility, until chef can be profoundly upgraded to
support dnf. Similar issues will occur with cfengine and many, many
other system management utilities.

I think the name change helps make clear that it's an architectural change.

> So Yum has been made faster? That's wonderful news, it was certainly
> needed. It's been redesigned and largely rewritten? OK, great, I

I'm afraid that It's also a fairly irrelevant speed improvement. Many
of the underlying delays in yum are due to the excessively bulky
repodata, which requires complete binary replacement every time yum
metadata expires due to its overburdened and monolithic compressed
binary format. Unless 'repodata' is extensively rewritten, with much
smaller and easily synchronzed components and not this monolithinc and
increasingly encumbered SQLite database of doom, small operations such
as "yum check-updates"  are likely  to continue to suck bandwidth,
CPU, and resources excessively every time they get run.

If you think I'm kidding, switch to a local yum mirror and check the
logs for *just how many times*, the repodata gets downloaded with
standard configurations in a busy environment. The bandwidth saved by
using delta-rpms is completely irrelevant compared to the expensive
repodata refreshes, themselves, in an environment where yum checks, or
system tools that verify yum dependencies, run even once a day.
Frankly, improving that might be enormously helpful to the Fedora
mirrors themselves. The investment in server side operations to check
a larger list of smaller and more stable metadata components would, I
think, be well justified by replacing the quite builky, monolithic,
and expiration envorced sqlite database files.

I'd love to see dnf speed improvements improve the behavior of tools
like 'mock', which rely so heavily on yum updates. But given the
bandwidth and resource constraints of repodata churn, I don't think
it's gonna happen.

> As a system administrator I expect "yum install", "yum remove" and
> "yum update" to continue to work, and I expect to not have to rename or
> edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.

That's why they're changing the name: it's a major architectural shift
in a core component, and continuing to call it yum, could be
confusing.

> As a fellow programmer I can understand that you want to use a new name
> for this new and improved program that you have invested a lot of work
> in, but I also know how annoyed I would be if I had scripts calling Yum,
> and had to modify them to keep them working. A command line interface
> is also an API, and I want APIs to be as stable as possible so I can
> spend my time writing new programs instead of rewriting old programs
> just to keep existing functionality. It's particularly painful when a
> program must be ported or branched to work on different systems, for
> example Fedora and RHEL, because one has only the old API and the other
> has only the new API.

And the API changing is pretty profound. It's a different API, thus a
different function name.

And yeah, I'm not personally looking forward to it. I still loathe the
switch to systemd for systems I maintain in multiple environments.

> --
> Björn Persson
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct