From Fedora Project Wiki
No edit summary
No edit summary
Line 22: Line 22:


== Detailed Description ==
== Detailed Description ==
DNF is a fork of Yum 3.4 that uses libsolv for a backed. The main goals of the project are:
* using a SAT solver for dependency resolving
** allowing us to eventually use the same solver in rpm too
* strict API definition for plugins
* strict API definition for extending projects (Anaconda)
* leaner codebase than Yum, allowing for easier maintenance
* better performance and footprint.
For Fedora 18 this is mainly meant as a preview. The package can be installed along yum so user's workflow is not disturbed when DNF malfunctions.
The effort on DNF happens in parallel to the [[Features/Hawkey|Hawkey development]], a library providing simplified libsolv C and Python bindings.


=== Comparing to zif ===
=== Comparing to zif ===
Line 30: Line 41:


== Benefit to Fedora ==
== Benefit to Fedora ==
Faster and simpler package manager. Eventually simplified client code.


== Scope ==
== Scope ==
Line 47: Line 59:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
Unit tests included.
Manual testing is done by performing actions one would normally do through yum, e.g. 'dnf install virt-manager'.


== User Experience ==
== User Experience ==
To test-drive dnf use 'dnf <command>' instead of 'yum <command>'. list/update/install/erase are currently all supported.
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
This feature will not disturb any existing Fedora software.
In the future if DNF gets accepted as the main package manager of the platform, yum plugins will have to be updated for the new API and so will Anaconda. I am prepared to assist in this effort with documentation and patches.


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
If DNF doesn't work the user can use yum instead.


== Documentation ==
== Documentation ==
Maintained [https://github.com/akozumpl/dnf/wiki at github wiki].


== Release Notes ==
== Release Notes ==

Revision as of 14:55, 31 May 2012


DNF, a new Package Manager

Summary

A preview of the next-generation Yum package manager, using hawkey/libsolv for backend.

Owner

Current status

  • Targeted release: Fedora 18
  • Last updated: 2012-05-31
  • Percentage of completion: 40%


Detailed Description

DNF is a fork of Yum 3.4 that uses libsolv for a backed. The main goals of the project are:

  • using a SAT solver for dependency resolving
    • allowing us to eventually use the same solver in rpm too
  • strict API definition for plugins
  • strict API definition for extending projects (Anaconda)
  • leaner codebase than Yum, allowing for easier maintenance
  • better performance and footprint.

For Fedora 18 this is mainly meant as a preview. The package can be installed along yum so user's workflow is not disturbed when DNF malfunctions.

The effort on DNF happens in parallel to the Hawkey development, a library providing simplified libsolv C and Python bindings.

Comparing to zif

People are asking why we didn't choose to adopt zif instead of fixing yum. The reasons are:

  • dnf looks for a middle ground between a sane API and some backwards compatibility.
  • dnf and hawkey are first steps toward using the same resolver accross the entire stack.
  • Libsolv is a well tested and proven code base, currently the most sophisticated and optimized dependency solving implementation.

Benefit to Fedora

Faster and simpler package manager. Eventually simplified client code.

Scope

How To Test

Unit tests included.

Manual testing is done by performing actions one would normally do through yum, e.g. 'dnf install virt-manager'.

User Experience

To test-drive dnf use 'dnf <command>' instead of 'yum <command>'. list/update/install/erase are currently all supported.


Dependencies

This feature will not disturb any existing Fedora software.

In the future if DNF gets accepted as the main package manager of the platform, yum plugins will have to be updated for the new API and so will Anaconda. I am prepared to assist in this effort with documentation and patches.

Contingency Plan

If DNF doesn't work the user can use yum instead.

Documentation

Maintained at github wiki.

Release Notes

Comments and Discussion