Announcement

Collapse
No announcement yet.

DNF - Next-Generation Yum - Keeps Pushing Forward

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

  • DNF - Next-Generation Yum - Keeps Pushing Forward

    Phoronix: DNF - Next-Generation Yum - Keeps Pushing Forward

    DNF, the next-generation version of the Yum package manager, saw a new release today and with it comes two new major features...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    In the sailing world, DNF equates to Did Not Finish; meaning a competitor did not finish a race.

    Originally posted by phoronix View Post
    Phoronix: DNF - Next-Generation Yum - Keeps Pushing Forward

    DNF, the next-generation version of the Yum package manager, saw a new release today and with it comes two new major features...

    http://www.phoronix.com/vr.php?view=MTQ5OTI

    Comment


    • #3
      Duke Nukem Forever - The Next Generation is Yummy


      That's what I did read, really....

      Comment


      • #4
        Originally posted by timofonic View Post
        Duke Nukem Forever - The Next Generation is Yummy


        That's what I did read, really....
        You are not alone ...

        Comment


        • #5
          Originally posted by akincer View Post
          You are not alone ...
          Both names are jokes amongst the DNF's devs, but it seriously doesnt matter. The plan is to get DNF stable and working and then sometime in the future (current plan is Fedora 21 or 22 from what Ive read) rename DNF to yum and push it out. So everyone's gonna keep using 'yum install' 'yum update' etc etc etc
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            The solution we needed 5 years ago, not now

            Always happy to see new projects being started, but honestly, it would be nice to see someone working on a packaging tool designed to cover both APT and RPM instead, so that we can start consolidating (and maybe even developing a universal format that can transparently be added into either packaging system).

            Comment


            • #7
              Originally posted by Auzy View Post
              Always happy to see new projects being started, but honestly, it would be nice to see someone working on a packaging tool designed to cover both APT and RPM instead, so that we can start consolidating (and maybe even developing a universal format that can transparently be added into either packaging system).
              Well you have a bit of a problem in that the package would have to list its dependencies... and every distro has a different way of listing packages.. Personally I'm a fan of Arch and Fedora's way of doing package names and package versions. The debian / Ubuntu style always seemed really cluttered and confusing.

              So let's get everyone listing packages and package versions the same WAY, and then we'll worry about making a tool that can handle the differences.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #8
                I've been using OpenSuse 13.1 for a little bit now (wewt, two weeks!) and loving it 'heaps'. I remember it used to use yum, though 'back in the day'. I was gonna make yummy alias to yum. No worries though, yummy can alias to zypper (my gawd, what a sweet tool).
                Hi

                Comment


                • #9
                  i get disgusted, why not one rpm/deb mix that works everywhere?

                  Comment


                  • #10
                    Originally posted by mike4 View Post
                    i get disgusted, why not one rpm/deb mix that works everywhere?
                    Distros have different packages, different names FOR those packages, different package versions.

                    Perfect example: the new steam binary that its RPMFusion won't work on RHEL 6 (currently released version), but it works perfectly fine on Fedora 18 and 19. RHEL has all of the packages necessary if you just look at them by name.. But if you try to install it, it wont work. Why? The version of glibc on RHEL is too old.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X