Fedora's Engineering Steering Committee (FESCo) recently voted
to approve an additional feature for Fedora 18: a new alternative
package manager called DNF. The primary author
intends for DNF to
replace Fedora's current package manager, Yum, but there are questions
as to when it will be ready and why starting over is
preferable to updating the existing code.
A handful of news sites reported DNF as "the" new package manager for
Fedora, which might lead one to conclude that it will be the default
option. However, DNF is only approved for inclusion in Fedora 18, as
it does not have feature-parity with Yum and is still in heavy
development. Yum will remain the system package manager, and may for
several more releases.
DNF is the creation of Red Hat's Aleš Kozumplík, and is a fork of Yum
3.4 that uses his own hawkey library to
resolve package dependencies. Like Yum, DNF sits on top of the
lower-level rpm package installer; its purpose is to simplify package
installation, update, and removal by automatically calculating
dependencies and handling the management of dependent packages. The moniker "DNF" officially stands for
nothing, and was chosen by Kozumplík solely as a placeholder, although
the choice prompted humorous responses that it stood for
un-complimentary phrases like "Did Not Finish" or the oft-maligned
Duke Nukem Forever. Hawkey itself is a wrapper around the
resolver from openSUSE.
Some of the goals described on the wiki page
include providing API access to languages in addition to Python (which
is currently Yum's only option), a "strict" API, and better
Migrating the package manager to libsolv is the primary goal, however,
with an eye toward eventually using libsolv as the dependency solver
for RPM itself, as well as making it available to other programs that
handle package management, such as the installer. For users, a
libsolv-powered DNF's principal advantage over Yum is expected to be its
speed. At FUDCon in February, for example, Yum was described as being
four times slower than untar, which no one seems to regard as
Libsolv gains its advantage by using a modern
satisfiability-solving algorithm (or "SAT solver"), rather than the
ad-hoc dependency checking methods employed by other major Linux package
managers. Libsolv's documentation
that most package managers are optimized to find
updates to currently installed packages, with extensions tacked on to
handle other situations, resulting in slow and unpredictable code.
Libsolv uses a reimplementation of the open source Minisat solver, and has been adopted by openSUSE's Zypper package manager.
Integration with Fedora
DNF uses the more modern libsolv for improved dependency solving,
but it does not implement all of Yum's other features. The missing
generated some feedback from administrators who were upset that some
of the features they depend on had evidently been marked as
deprecated. For example, Yum has a "history" function that allows the
user to investigate logged installation and update actions, and even
roll them back, but the feature was listed on DNF's features
considered for dropping page. When fans of the feature complained
about its removal, Kozumplík agreed
to implement it in a future version.
DNF also lacks PackageKit integration, which PackageKit
maintainer Richard Hughes cited as a major problem during the FESCo
about approving the feature. Others in the discussion were unclear as
to the justification and plans for DNF to replace Yum. Bill
Nottingham asked why a fork was necessary, and Matthew Garrett asked:
Is this intended to prototype functionality that'll head back
to yum? Or is it going to sit there as an alternative and some time
later we'll have a contentious argument about defaults?
FESCo eventually voted to approve the feature on the grounds that (as
Miloslav Trmač put it) it was a "'we added a package, please
come and play with it' kind of feature, not 'this is a change for
everybody' kind of feature.
Distinct from the issue of advertising DNF's readiness too soon is the
concern that Kozumplík appeared to have launched the project without
first attempting to implement his changes within the main Yum trunk or
working with the Yum team. Yum developer Tim Lauridsen asked on the
desktop-devel mailing list:
Would it not be better to work with yum upstream to make the current yum
depsolver more modular so you could plugin another libsolv based depsolver,
instead of making a fork of yum and starts trashing the current API. There
is a lot more to yum, that just solving dependencies. And making a fork
there is not fully compatible will put a lot of work on your shoulders :)
without the benefit on the work done by yum upstream :) like parallel
Kozumplík replied that a fork was required to clean up the Yum API; deprecating legacy interfaces without worrying about simultaneously preserving backward compatibility. He also said
that he is collaborating with the Yum team, which Seth Vidal called
a contradiction, considering Lauridsen's question:
Tim _IS_ a yum developer. That he felt surprised by this means you've
only been communicating with yum devs on the internal red hat packaging
team not in the community channels related to yum specifically. It would
make good sense if you want to figure out what apis are important/matter
to discuss this on the yum-devel mailing list at the very least.
The future of solving
Of course, maintaining the delicate balance between paid-company-developers and community developers is a challenge on which most corporate
distributions spend a lot of time. At least the two camps appear to be talking now. Doubtless there is
interest in the improvements offered by a libsolv-based backend from
the Yum project, particularly as other pieces of the Fedora
infrastructure (including rpm itself and the installer) move toward it. Libsolv is gaining supporters among other projects as well (Hughes, for instance, is also the
author of the alternative package manager zif, and
indicated he was planning to migrate it to libsolv in the future). There does not appear to be a plan to migrate apt or apt-rpm to libsolv, but there has been interest in writing a new SAT solver to replace apt's current dependency resolver.
But agreement on the goal does not make the process any less arduous;
there are inherent difficulties in replacing a piece of software as
close to the core as Yum. Dependency resolving is complicated by the
number of options an RPM package can declare, such as specific
versions of some libraries or "recommended" packages that a user might
select (thus adding still more dependencies to the puzzle). There are
also scenarios where a user wants to swap out one package for another,
and would prefer to leave the common dependencies in-place in order to
cut down on time required. Despite the fact that openSUSE has been
using libsolv in its own package manager Zypper, hawkey and DNF
will require a lot of testing to get all of the corner cases correct.
Until then, Fedora users can count on Yum staying right where it is.
Comments (8 posted)
Kitten discussions probably don’t belong here, unless the kitten in
question is surprisingly adept on the command line.
-- Ubuntu IRC Council Blog
This is a development list, after all, not a ranting list.
-- Bill Nottingham
Comments (1 posted)
The first release candidate for the CyanogenMod 9.0 Android distribution is
this will be the first CyanogenMod release based on Android 4.0 ("Ice
"It wasn’t quick or easy, but we are extremely proud of this release
and what it represents for us as a group. The jump from 2.3.7 to 4.0.4 in
many ways was a fresh start for this project, and as much as the code
changed, the structure and organization of CM as a whole changed as
well. It meant a lot of hard work, and late nights, but also a ton of
fun. We are in this for the challenge, and the reward is always the
satisfaction received when we release it to the masses as a ‘stable’
product. This RC1 brings us a step forward toward that payoff.
Comments (50 posted)
Red Hat Enterprise Linux 6.3 has been
. The release notes are
. From a review
at The H: "RHEL 6.3 officially supports allocating up to 160 processor cores and 2TB of working memory to guest systems; previously, the distribution only supported 64 cores and 512GB of RAM. Spice, which is involved in virtualising desktop PCs, can now pass through USB 2.0 devices from the system that is displaying the desktop to a local or remote virtualised guest operating system. Another new feature is support for SR-IOV-capable (Single Root I/O Virtualisation) networking hardware which can present a single physical card as multiple, separate virtual network cards; this support allows these virtual network cards to be allocated to guest systems.
Comments (17 posted)
James Bottomley has announced the availability of a version of the Tianocore
built into a KVM virtual machine; the result is a virtual system
implementing the UEFI secure boot mechanism. "I'm releasing this now
because interest in UEFI Secure Boot is rising, particularly amongst the
Linux Distributions which don't have access to UEFI secure boot hardware,
so having a virtual platform should allow them to experiment with coming up
with their own solutions.
" It should be a useful tool for anybody
wanting to make a system that works within the UEFI secure boot environment.
Full Story (comments: 3)
The Open webOS project has announced
an interim source release called the "Community Edition". "The
Community Edition is focused on supporting the TouchPad. By contrast, the
Open webOS 1.0 release planned for September includes modernized
technologies to better enable the community to port webOS to the hardware
of their choice, and to integrate open source technologies in areas such as
BlueZ bluetooth and GStreamer.
Comments (11 posted)
The Debian release team has announced the Wheezy freeze on June 30.
Packages will no longer migrate automatically from unstable (sid) to
testing (Wheezy) at that time.
Full Story (comments: none)
John Rose (aka inode0) has been appointed to fill the final slot on the
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
Earlier this month LWN covered the
of an initial x32 release candidate of Gentoo. The x32
ABI enables the running of processes in 64-bit mode while using 32-bit
pointers. Gentoo developer Diego Elio "Flameeyes" Pettenò isn't
that x32 is the way to go, and debunks some common
misconceptions about the x32 ABI. "The new x32 ABI has proven to be faster. Not really; what we have right now are a few benchmarks, published by those who actually created the ABI, Of course you’d expect that those who spent time to set it up found it interesting and actually faster, but I honestly have doubts about the results, for reasons that will be clearer by reading the next few entries.
Comments (112 posted)
Ars technica takes
at Android 4.1 (Jelly Bean). "For developers, the Jelly
Bean SDK will include a new profiling tool, systrace, that provides a clear
visualization of their applications' use of the CPU, GPU, and other system
components, so that bottlenecks can be more readily identified and
" More information can be found in the Jelly
Bean platform highlights
Comments (22 posted)
Page editor: Rebecca Sobol
Next page: Development>>