Announcement

Collapse
No announcement yet.

Details Of DNF Succeeding Yum In Fedora 22 Still Being Discussed

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

  • Details Of DNF Succeeding Yum In Fedora 22 Still Being Discussed

    Phoronix: Details Of DNF Succeeding Yum In Fedora 22 Still Being Discussed

    With the upcoming release of Fedora 22, DNF is succeeding Yum as the default package manager. However, some details about this change are still being discussed...

    http://www.phoronix.com/scan.php?pag...2-Yum-Concerns

  • gilboa
    replied
    Originally posted by edmon View Post
    It is 2015 and for all rpm based distributions it is still problem to upgrade from one release to next one without some magic!
    It is obvious package type problem if no one can achieve it.
    It is easy to write package manager for dpkg this is why there is so many of them and only two for rpm.

    And it is very ugly when under your name is written for whom you work and to start talk about other distributions. this seems to be your company PR problem
    I manage >50 (closing on 100) different Fedora machines ranging down from low-end VMs and low-end netbooks up to high-end Xeon workstation and servers.
    I upgrade them from one version to another using fedup.
    Upgrading Fedora 20 to 21 simply worked. Period.

    Care to backup your statement with actual numbers?

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Luke_Wolf View Post
    And was it really worth it to spend 2 years writing Hawkey and DNF when it turned out you needed to write a yum compat facade on top of it anyway? Frankly, I would call that a failure, unless your desires were actually "We want a python version that better resembles yum than zypper does" which would be a perfectly valid reason but that's not the reason being claimed as that's not the same thing as "Backwards Compatibility" which you have failed at achieving as shown by the need for the facade.

    All I'm asking is consistency between word and action.
    Let's get something straight. I am not involved with dnf development and would prefer to just continue using yum as the command line.

    Having said that, backward compatibility isn't limited to the command line. Speaking to your point, it involves working with tools that use Python extensively including Koji, Mock, Anaconda etc. This isn't a new thing

    http://fedoraproject.org/wiki/Features/DNF

    "Hawkey clients will get:
    • easier bindings to other languages than Python"


    A major portion of the time spent on this is coordinating development and integration with a large number of tools. Not just dnf itself. Was it worth it? dnf developers obviously thought so and Fedora has accepted that rationale. You are free to disagree but calling it a facade is going too far.
    Last edited by RahulSundaram; 04-08-2015, 02:17 PM.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by RahulSundaram View Post
    libzypp is merely a convenience library. dnf and PackageKit backend that uses libsolv has one as well but the point is that the core library that does dependency solving is shared between dnf and zypper.
    And was it really worth it to spend 2 years writing Hawkey and DNF when it turned out you needed to write a yum compat facade on top of it anyway? Frankly, I would call that a failure, unless your desires were actually "We want a python version that better resembles yum than zypper does" which would be a perfectly valid reason but that's not the reason being claimed as that's not the same thing as "Backwards Compatibility" which you have failed at achieving as shown by the need for the facade.

    All I'm asking is consistency between word and action.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Luke_Wolf View Post
    No. Zypper is a command line over libzypp, libsolv is the dependency solver that libzypp uses.
    libzypp is merely a convenience library. dnf and PackageKit backend that uses libsolv has one as well but the point is that the core library that does dependency solving is shared between dnf and zypper.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by RahulSundaram View Post
    Zypper is just a command line over the library libsolv and that has been extended during the process of developing dnf and is used by it. So yeah pretty much what you described under the hood.
    No. Zypper is a command line over libzypp, libsolv is the dependency solver that libzypp uses.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Luke_Wolf View Post
    You could have done the same thing with zypper (extending it to support any missing features
    Zypper is just a command line over the library libsolv and that has been extended during the process of developing dnf and is used by it. So yeah pretty much what you described under the hood.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by RahulSundaram View Post
    That is not what the script does. It has a message in front saying yum is deprecated but it also automatically redirects to dnf. So it works more like an alias. This maintains backward compatibility for the most part (dnf and yum have *mostly* similar options but it is not 100%) while allowing a transition period. This is pretty similar to how service command in Fedora redirects to systemctl automatically.
    You could have done the same thing with zypper (extending it to support any missing features), and spared yourselves the time developing DNF. I understood and respected the need for DNF when it was just yum-ng, with DNF being a temporary name for the purposes of having a different binary so that yum and DNF were co-installable while it was being developed, and the plan was to rename it to yum when it was finished. I am sympathetic to the need for backwards compatibility.

    This however is not what was sold to us. If you're using a script to create a facade for yum with a deprecation warning (I presume the script will be removed in the future), then there's no reason for DNF to have been created as opposed to just using zypper. Unlike with display servers I'm not particularly against there being a billion different package managers, but ffs don't declare a rationale for creating replacement software and not using an alternative, and then trample all over that rationale.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by droidhacker View Post
    Well, the difference here is that systemctl isn't a "drop in" replacement for 'service'. It is something new entirely, and the current 'service' command is a lot more complex than the current 'yum' command, since it has to reformat the input parameters to match systemctl.
    That is a implementation detail. I was just noting that the redirection was inspired by systemctl.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by nanonyme View Post
    Except that yum's features are a superset of dnf's features so not everything can be redirected. Eg yum's transactional shell is a highly powerful feature through which you could basically do anything else that's missing in dnf if it was implemented. I mean, fine, it's manual repair but it allows people to carve you a manual transaction that will fix your system in a support channel
    I am not sure what you are disagreeing with since I already mentioned that dnf and yum is not 100% compatible. You can't really implement anything new in a yum shell. It merely uses existing functionality interactively and doesn't apply to backward compatibility in the context of shell scripts.

    Leave a comment:

Working...
X