DNF

Announcing DNF 3 development

Thu, 22 Mar 2018 12:00:00 +0000

We are pleased to announce that development of DNF 3 has started. This version focused on performance improvements, new API and consolidating the whole software management stack. That's why the rest of the text is more about libdnf than DNF, which should become smaller and only wrap underlying libdnf library.

What's going on with libdnf?

If you are watching DNF and libdnf development, you may ask what's going on lately. There is a lot of activity in libdnf GIT. Let us share our plans with you. Originally there were two libraries - hawkey providing query and dependency resolution interface to DNF and libhif as a PackageKit backend. These two merged into libdnf, but the merge hasn't been fully finished. The technical debt grows as new code is being added and there's even disparity between libdnf and DNF. We decided to change this and make libdnf sane again.

Improvements made so far

We made several improvements to queries already. They are executed as part of all DNF commands and have significant performance impact. We focused mainly on security queries and searching packages by Name or full NEVRA.
Let's look at some numbers. The chart shows execution times (lower is better) of several DNF commands using 3 different versions of libdnf:

0.9.1 - initial version in Fedora 26
0.11.1 - latest released version in Fedora 26 and 27
0.13.0 - development version in GIT

What we want to achieve

Performance improvement
Consistent behavior across the whole software management stack
- Move existing business logic from DNF to libdnf
- Remove duplicate code
Well-defined and maintainable API
New high-level functionality (like “dnf.Base()”)
Remain compatible with existing APIs (C/Python) as much as possible

How to move forward

We decided to move libdnf from C to C++ for several good reasons:

C++ is a standardized object-oriented language with good compiler support
Existing C code compiles with C++ compiler - we can reuse some existing code as is
C++ 11 is supported by GCC in RHEL 7 / CentOS 7
C++ has more "batteries included" than C (classes, vectors and maps, shared pointers, algorithm library, etc.)
You don't have to worry about raw pointers in C++.
SWIG bindings (C++ objects wrapped in shared pointer naturally bind to Python objects)

Road-map

Doing all the consolidation, we have a unique opportunity to redesign libdnf. This is what we are planning:

Preparation (mostly done)
- Remove unused functionality
- De-duplicate some code between DNF and libdnf
DNF Integration (in progress)
- Design new functionality in libdnf, and replace corresponding DNF code in Python
Redesign libdnf
- Split libdnf into subsystems
- Provide new high-level interface (replacing dnf.Base and libdnf context)
Broader integration
- Use the new libdnf API in PackageKit, rpm-ostree and microdnf

Benefits

You may ask: "How will I benefit from all these changes?" First of all, you will get consistent user experience from all software management tools. Wouldn't it be great if PackageKit and DNF shared repository and package cache? And that's just a tip of the iceberg. You will also get much better performance, because the DNF team has been analyzing the whole stack. Asking "why" often results in removing bottlenecks all over the place.

DNF performance boost

Thu, 23 Nov 2017 13:00:00 +0000

Since the last blog there were several releases that enhance functionality and mostly performance especially visible with multiple package arguments. Just try "dnf --assumeno reinstall $(rpm -qa)" with libdnf-0.9.0 and libdnf-0.11.1 and differences is easily visible. But the real huge improvement can be seen when results are compared to YUM.

DNF-2.7.5

Enhanced performance for excludes and includes handling
Solved several memory leaks
Additionally 8 bug reports solved
Detailed information about DNF releases

DNF-PLUGINS-CORE-2.1.5

Added four new options for list subcommand of copr plugin
Additionally 2 bug reports solved
Detailed information about DNF-PLUGINS-CORE releases

DNF-PLUGINS-EXTRAS-2.0.4

Fixed several issues of system-upgrade plugin
Detailed information about DNF-PLUGINS-EXTRAS releases

LIBDNF-0.11.1

Huge performance boost for queries with arch and name filters (20x boost)
Additionally 4 bug reports solved

The first DNF update for Fedora 26

Wed, 02 Aug 2017 06:01:04 +0000

The release of Fedora 26 provides the new DNF-2.x to wide pool of users. The first DNF update reflect the first user's feed backs and additionally it solves 23 bugs. The latest release has provided the following highlights: DNF-2.6.2

New option --forcearch=<arch> that force to use given architecture. However, use of an architecture not supported natively by your CPU will require emulation of some kind. This is usually through QEMU
New option --groupmember for repoquery command
New option --downloaddir <path> that can be combine with --downloadonly option
Inform about skipped packages during installation of groups
New conf options (basearch, arch, ignorearch)
Detailed information about DNF releases

DNF-PLUGINS-CORE-2.1.3

Changed return code if dnf config-manager --add-repo fails
Detailed information about DNF-PLUGINS-CORE releases

LIBDNF-0.9.3

Changed priorities in NEVRA parsing. This change should provide user preferred results especially in cases where multiple valid solution available.

Release of the latest candidates of dnf stack for Fedora 26

Thu, 15 Jun 2017 06:07:10 +0000

I think if I will start to talk that Fedora 26 is coming and that there will be DNF-2.x as default packager, I am not providing any new information. But If I will say that DNF made a huge progress not only from point of presence of new features, enhanced stability and over all user experience, probably it would be something to attract people's attention. The latest releases have provided the spirit with following highlights: DNF-2.5.1 (since 2.4.1)

Redesigned reports of problem. Now package upgrades will be not skipped silently
Implemented progress of DRPM
Localized datetime format
Enhanced documentation
Detailed information about DNF releases

DNF-PLUGINS-CORE-2.1.1 (since 2.0.0)

Introduced DNF-UTILS subpackage that provides binaries previously known from YUM-UTILS
Enhanced documentation of plugin Versionlock
Plugin Versionlock will be not applied for commands without transaction like list, info, repoquery ...
Detailed information about DNF-PLUGINS-CORE releases

DNF-PLUGINS-EXTRAS-2.0.1 (since 2.0.0)

Check if plugin is removed in trans
Detailed information about DNF-PLUGINS-EXTRAS releases

LIBDNF-0.9.1 (since 0.8.3)

Improved handling of installonly packages and running kernel protection
Improved reports from libsolv (no redundant messages in particular problem set)
Install packages with lover version than already installed will allow downgrade of dependencies
Methods (problem_conflicts(), problem_broken_dependency()) from python API where moved into C code
Python property problem_rules where changed to method and moved into C code

Additionally all of this releases fixes together over 30 bugs in whole DNF stack.

DNF 2.4.1, DNF-PLUGINS-CORE 2.0.0, DNF-PLUGINS-EXTRAS 2.0.0, and LIBDNF 0.8.3 have been released

Thu, 11 May 2017 09:47:29 +0000

The main aspect of the release is movement of several plugins from dnf-plugins-extras to dnf-plugins-core that became a part of core package or a separate sub-package. The release also provides new dnf option --enableplugin= , new option --userinstalled for REPOQUERY, and enables auto-detection of releasever from host if --releasever=/ is used. Additionally it fixes over 14 bugs in whole DNF stack, like a performance issue of VERSIONLOCK plugin, and added progress bar for download packages from command-line. For complete list of changes see DNF, DNF-PLUGINS-CORE and DNF-PLUGINS-EXTRAS release notes.

New DNF Project Leader

Sat, 29 Apr 2017 19:54:45 +0000

I'd like to announce new team leader of DNF project as I decided to accept new challenges in a different environment. From May 1 Daniel Mach will be officially new team lead of the project. He came from release engineer background and has been consumer of DNF for a long time. Because of his knowledge of the ecosystem and ability to push things forward I believe he will fit into this role well. I will still keep an eye on the project but now more like its user and occasional contributor. Thank you all who cooperated to make DNF better. Jan

DNF 2.3.0 was released

Mon, 24 Apr 2017 08:20:12 +0000

DNF 2.3.0 was released. The release adds new API property for Package class to return location from where the package can be downloaded from. The release introduce 7 new options for repoquery command, that were known from YUM. Additionally it fixes 4 bugs. For complete list of changes see DNF release notes.

DNF 2.2.0, and LIBDNF 0.8.0 were released

Mon, 03 Apr 2017 15:07:25 +0000

DNF 2.2.0, and LIBDNF 0.8.0 were released. The release adds new API for adding and initialization of new REPO object into REPODICT class. Also interesting could be a new API callback that allows to inform users about running scriplets during RPM transaction. Additionally it also fixes over 13 bugs. For complete list of changes see DNF release notes.

DNF 2.1.0, DNF-PLUGINS-CORE 1.0.0 and DNF-PLUGINS-EXTRAS 0.10.0 has been released

Fri, 03 Mar 2017 15:12:07 +0000

DNF 2.1.0, DNF-PLUGINS-CORE 1.0.1, and DNF-PLUGINS-EXTRAS 0.10.0 released. Whole DNF stack release fixes over 20 bugs. DNF stack release is focused on bug fixes and yum-dnf compatibility. The release also provides two new commands (shell, and swap) that are formally known from YUM. For complete list of changes see DNF, DNF-PLUGINS-CORE and DNF-PLUGINS-EXTRAS release notes.

DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released

Tue, 20 Dec 2016 07:30:06 +0000

DNF-2.0 has been released! The next major version release of DNF brings many user experience improvements such as better dependency problem reporting messages, weak dependencies shown in transaction summary, more intuitive help usage invoking and others. Repoquery plugin has been moved into DNF itself. Whole DNF stack release fixes over 60 bugs. DNF-2.0 release is focused on improving yum compatibility i.e. treat yum configuration options the same (`include`, `includepkgs` and `exclude`). Unfortunately this release is not fully compatible with DNF-1. See the list of DNF-1 and DNF-2 incompatible changes. Authors of dnf plugins will need to check compatibility of their plugins with the new DNF argument parser. For complete list of changes see DNF and plugins release notes.