Yum Set To Be Retired In Fedora 29

[phoronix]

Phoronix: Yum Set To Be Retired In Fedora 29

While DNF has been serving as the "next-gen Yum" by default since Fedora 22, Yum 3 has still been present in releases since. But with Fedora 29 they are looking to deprecate and remove Yum...

http://www.phoronix.com/scan.php?page=news_item&px=Yum-3-Retiring-Fedora-29

[Chewi]

While dnf did seem faster initially, for the past year or so, it's been a total dog. I've just done a rather unscientific "time sudo dnf search postgres" and it took 3m24s. It spent most of that time churning the disk. My LVM PV is LUKS encrypted but still.

[emblemparade]

I wonder if this means that "/etc/yum.repos.d/" will stop being the default repo location. (Though I'm sure it will have to be supported in the path for several versions to come, for backward compatibility.)

[RahulSundaram]

I wonder if this means that "/etc/yum.repos.d/" will stop being the default repo location. (Though I'm sure it will have to be supported in the path for several versions to come, for backward compatibility.)

dnf reads that path and will continue to do so for the foreseeable future.

[mskarbek]

I wonder if this means that "/etc/yum.repos.d/" will stop being the default repo location. (Though I'm sure it will have to be supported in the path for several versions to come, for backward compatibility.)

There was already discussion in Fedora community about that and proposition to drop "yum." -> "/etc/repos.d". Long story short "/etc/yum.repos.d/" will stay with us.

[Candy]

While dnf did seem faster initially, for the past year or so, it's been a total dog.

I made the same experiences. DNF became quite slow. Slower than YUM.

[RahulSundaram]

I made the same experiences. DNF became quite slow. Slower than YUM.

Anything you can benchmark and file a report on?

[eydee]

They should keep the command itself, redirected to dnf, because of muscle memory.

[browseria]

While dnf did seem faster initially, for the past year or so, it's been a total dog. I've just done a rather unscientific "time sudo dnf search postgres" and it took 3m24s. It spent most of that time churning the disk. My LVM PV is LUKS encrypted but still.

Fedora Server 28, XFS, "real" hardware (about 2 months old):
| sudo dnf search postgres
| Time: 2.097s total time, 1.96s user time, 0.12s kernel time
| Disk: 0 major page faults (pages loaded from disk)
| System: 99% CPU used, 112 MB max memory used

Fedora Workstation 28, ext4, KVM image (upgraded from Fedora 27, about 9 months old):
| sudo dnf search postgres
| Time: 1.013s total time, 0.88s user time, 0.12s kernel time
| Disk: 0 major page faults (pages loaded from disk)
| System: 98% CPU used, 119 MB max memory used

Fedora Workstation 27, ext4, "real" hardware (about 9 months old):
| sudo dnf search postgres
| Time: 0.996s total time, 0.82s user time, 0.14s kernel time
| Disk: 8 major page faults (pages loaded from disk)
| System: 96% CPU used, 117 MB max memory used

Fedora Workstation 27, ext4, KVM image (about 14 months old):
| sudo dnf search postgres
| Time: 1.735s total time, 1.44s user time, 0.27s kernel time
| Disk: 0 major page faults (pages loaded from disk)
| System: 98% CPU used, 124 MB max memory used

I could go back farther, but I don't think I'm going to get significantly different results...are you sure it's DNF that is the problem?

[Zan Lynx]

While dnf did seem faster initially, for the past year or so, it's been a total dog. I've just done a rather unscientific "time sudo dnf search postgres" and it took 3m24s. It spent most of that time churning the disk. My LVM PV is LUKS encrypted but still.

There's something horribly broken with your system. Here's mine:

$ time sudo dnf search postgres
...
real    0m0.925s
user    0m0.818s
sys     0m0.100s