Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: DNF Still Advancing As Experimental Yum For Fedora

  1. #1
    Join Date
    Jan 2007
    Posts
    13,431

    Default DNF Still Advancing As Experimental Yum For Fedora

    Phoronix: DNF Still Advancing As Experimental Yum For Fedora

    DNF is the experimental fork of the Yum package manager that premiered in Fedora 18. While much hasn't been heard of this experimental Yum replacement since its debut, work on it has still been progressing and is turning out to be in great shape, is slowly approaching feature-parity with Yum, and is faster...

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

  2. #2
    Join Date
    Feb 2013
    Posts
    254

    Default

    Not really sure if Yum needs a replacement as much as configured differently upon default installation.
    The slowest part is that it doesn't use a cache like apt by default, using -C makes it just as fast as apt.

  3. #3
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Bash completion should take minutes to fix if it's CLI compatible with yum. Copy the completion script and s/yum/dnf/g.

  4. #4

    Default

    Quote Originally Posted by peppercats View Post
    Not really sure if Yum needs a replacement as much as configured differently upon default installation.
    The slowest part is that it doesn't use a cache like apt by default, using -C makes it just as fast as apt.
    dnf is just a prototype and the plan is for this to literally become the new yum so you wouldn't really notice that it has been replaced. dnf syncs the metadata using a systemd timer by default so wouldn't have to wait for it to be updated first typically. Fedora drops older packages beyond two versions from the master server to keep mirrors happy (its still retained in the build system so you can get it if you really want to) so if metadata isnt updated first, you might run into issues.

    @elanthis More or less, yeah. Copying and tweaking for slight differences. It is a easy fix.

  5. #5
    Join Date
    Dec 2010
    Posts
    1,056

    Default

    How to get a next generation YUM in minutes:
    1.) Fork zypper (front-end only, not libzypp)
    2.) Change the zypper commands to match YUM
    3.) Change the name of the zypper fork to YUM.
    Done.

  6. #6
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    Quote Originally Posted by Awesomeness View Post
    How to get a next generation YUM in minutes:
    1.) Fork zypper (front-end only, not libzypp)
    2.) Change the zypper commands to match YUM
    3.) Change the name of the zypper fork to YUM.
    Done.
    They would be better off just dropping yum and adopting zypper and libzypp.

  7. #7

    Default

    Quote Originally Posted by Awesomeness View Post
    How to get a next generation YUM in minutes:
    1.) Fork zypper (front-end only, not libzypp)
    2.) Change the zypper commands to match YUM
    3.) Change the name of the zypper fork to YUM.
    Done.
    A dependency resolver is very much a core component and you can't just swap one with another and really expect it to work and that is why a transition to libsolv needs a lot of testing and time to mature.

    yum's dependency resolving logic is different. SUSE has a number of distribution specific tweaks to RPM which aren't used outside the distribution but used by zypper and won't work in Fedora at all. Also yum has a number of commands including history etc which have no equivalent in zypper. In addition to that, yum is not just a end user tool but also provides the API that is used by all the different yum plugins, the build tools like mock and koji, qa tools and Anaconda, the installer itself.

    The good news is that when dnf becomes mature, libsolv as the key library will be shared by both Fedora and openSUSE and RPM developers have some potential plans merge it upstream as well.

  8. #8
    Join Date
    May 2012
    Posts
    675

    Default

    Quote Originally Posted by peppercats View Post
    The slowest part is that it doesn't use a cache like apt by default, using -C makes it just as fast as apt.
    Ah yes the wacko idea to update each time from the net that trickled down without notice upon desktop users from the server-side.

    I sometimes ask myself - how come crappy decisions like this happen, then I remember how nautilus by default (until like 2011) opened each dir in a new window on double click (thanks to Canonical for overriding this idiocy in Ubuntu by default), or how gedit by default shits out a hidden backup copy for every edited file ever littering your desktop computer with random garbage - and I give up.

    To companies: don't allow server side mentality/bigotry/paranoia to automatically trickle down onto the desktop, put a common sense filter in between.
    Last edited by mark45; 05-19-2013 at 05:35 AM.

  9. #9
    Join Date
    Dec 2010
    Posts
    1,056

    Default

    Quote Originally Posted by RahulSundaram View Post
    SUSE has a number of distribution specific tweaks to RPM which aren't used outside the distribution but used by zypper and won't work in Fedora at all.
    That's quite a strange statement considering that a few non-SUSE distributions already switched to zypper years ago, including the Fedora-derived Ark Linux distribution. I don't have a Fedora installation at hand right now but I'm sure you do. So why don't you add the upstream Fedora repo, install zypper, and tell us what exactly doesn't work.
    http://download.opensuse.org/reposit...ead/Fedora_17/

    Quote Originally Posted by RahulSundaram View Post
    Also yum has a number of commands including history etc which have no equivalent in zypper.
    Then add them to zypper. Red Hat has a great reputation for working upstream. Strange to see Canonical mentality creep into RH. “Upstream doesn't provide every last bit we want? Roll out our own solution instead.”

    Quote Originally Posted by RahulSundaram View Post
    In addition to that, yum is not just a end user tool but also provides the API that is used by all the different yum plugins, the build tools like mock and koji, qa tools and Anaconda, the installer itself.
    Deprecate the yum API and rather use the resources to port the other stuff to libzypp.

    Before DNF development started zypp was the only LSB-compatible package manager to be actively developed among all mainstream distributions.
    If the roles were reversed, I'd tell a SUSE engineer exactly the same thing: Drop your home-grown solution is favor of of the superior one by a 3rd party.

  10. #10
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,399

    Default

    Quote Originally Posted by Awesomeness View Post
    Red Hat has a great reputation for working upstream. Strange to see Canonical mentality creep into RH. “Upstream doesn't provide every last bit we want? Roll out our own solution instead.”
    Interesting that there are more distributions using zypper. But what does Red Hat have to do with all that to begin with?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •