Announcement

Collapse
No announcement yet.

Yum Set To Be Retired In Fedora 29

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Yum Set To Be Retired In Fedora 29

    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?pag...ring-Fedora-29

  • #2
    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.

    Comment


    • #3
      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.)

      Comment


      • #4
        Originally posted by emblemparade View Post
        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.

        Comment


        • #5
          Originally posted by emblemparade View Post
          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.

          Comment


          • #6
            Originally posted by Chewi View Post
            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.

            Comment


            • #7
              Originally posted by Candy View Post

              I made the same experiences. DNF became quite slow. Slower than YUM.
              Anything you can benchmark and file a report on?

              Comment


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

                Comment


                • #9
                  Originally posted by Chewi View Post
                  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?

                  Comment


                  • #10
                    Originally posted by Chewi View Post
                    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:

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

                    Comment

                    Working...
                    X