LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsDNF, which may or may not replace YumFedora'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 libsolv dependency 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 performance. 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 acceptable. 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 observes 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 FedoraDNF uses the more modern libsolv for improved dependency solving, but it does not implement all of Yum's other features. The missing functionality 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 debate 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
download etc.
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 solvingOf 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.
Brief items Distribution quotes of the week
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
CyanogenMod 9.0-rc1 availableThe first release candidate for the CyanogenMod 9.0 Android distribution is now available; this will be the first CyanogenMod release based on Android 4.0 ("Ice Cream Sandwich"). "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."
Red Hat Enterprise Linux 6.3Red Hat Enterprise Linux 6.3 has been released. The release notes are here. 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."
UEFI Secure boot using qemu-kvmJames Bottomley has announced the availability of a version of the Tianocore UEFI implementation 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.
Open webOS "Community Edition" releasedThe 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."
Distribution News Debian GNU/Linux Bits from the Release Team: Final countdown!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.
Fedora Fedora Board appointmentJohn Rose (aka inode0) has been appointed to fill the final slot on the Fedora board.
Newsletters and articles of interest Distribution newsletters
Pettenò: Debunking x32 mythsEarlier this month LWN covered the announcement 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 convinced 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."
Android 4.1 Jelly Bean: faster, smoother, more delightful (ars technica)Ars technica takes a look 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 resolved." More information can be found in the Jelly Bean platform highlights.
Page editor: Rebecca Sobol |
|||||||||||||