User: Password:
Subscribe / Log in / New account


Looking for zombies in Fedora

By Nathan Willis
January 29, 2014

Fedora is keen to make its Software Center a user-friendly application installer, so starting with Fedora 22 the distribution will require that each package listed includes a human-friendly description in its metadata. That is certainly a worthwhile goal, but along the way, the process of gathering that metadata revealed another question that all distributors grapple with: what should the distribution do with the scores of packages whose upstream projects are either missing or demonstrably dead.

The human-friendly description campaign is led by Richard Hughes. Roughly speaking, "human friendly" means an accurate description of the program, written in complete sentences, that explains its purpose to someone not already familiar with the project. Hughes started the AppData schema as a package-format-neutral way for applications to provide these descriptions themselves, and over the past few months has been urging upstream projects to write their own AppData descriptions.

The point is intended to be that a user-friendly "software installer" should let end users answer the question "Do I want to install this application?" based solely on the AppData description. The shorter, more functional descriptions already found in most RPM and Debian packages suffice for a lower-level package manager, where references to other packages and undefined acronyms (e.g., "ISC shared library used by BIND") do not actually impede usage.

But those differing use cases necessitate making some decisions about which programs belong in the user-friendly installer and which do not. Thus, Hughes spent a lot of time digging into Fedora's packages and assessing which programs belong where. He has also regularly reported back on the progress of AppData collecting, and on January 22, dropped an intriguing tidbit on the fedora-devel list:

I've now gone through the entire list of applications-in-fedora-without-appdata. A *lot* of those applications haven't seen an upstream release in half a decade, some over a decade. I would estimate that 40% of all the apps in Fedora are dead or semi-dead upstream.

40% sounds like an alarming portion, and others on the list quickly reacted with alarm. Jóhann B. Guðmundsson, for example, suggested removing packages with dead upstream projects, on the grounds that doing so would decrease the burden on Quality Assurance (QA) team volunteers. He did not garner much support for that drastic solution, however. For starters, as a number of people pointed out, the issue at hand was not whether or not to remove packages from Fedora entirely, but whether or not to include specific packages in the Software Center.

In fact, as the resulting sub-thread revealed, there was evidently a misunderstanding at the beginning: the 40% number is not the proportion of all Fedora packages whose upstream project is dormant, but rather the percentage of those packages that Hughes considered potential Software Center candidates—specifically, GUI applications, with .desktop files that do not set the NoDisplay=true" attribute and provide at least one application Category attribute. As Hughes later put it, he was thinking only of "crappy GUI applications that users install and then the application crashes, they report a bug or feature request, wait, and nothing happens as the upstream is long dead and there are going to be no more releases."

There are of course plenty of programs that have stopped receiving updates because there is little or nothing left to do. Przemek Klosowski cited the example of small, command-line utilities that do what they need to and have no real need for further development. Hughes's focus for the Fedora 22 Software Center is narrower, to be sure. The general consensus seems to be that users comfortable on the command line and looking for command-line utilities will prefer to use a command-line installer to install them.

That aside, though, the question remained whether there are Fedora packages that are abandoned upstream and genuinely do need to be culled—either because they no longer function correctly or for ancillary reasons like the increased potential of security vulnerabilities. Rahul Sundaram argued that there are valid scenarios in which a package with no upstream development should remain in Fedora. Fedora's package maintainers, he said, often fix bugs even when the upstream project in question has gone inactive.

They don't add any real overhead to Fedora and cutting them will just piss off users without any benefits. As long as package maintainers are willing to maintain them, there is no reason to mess with the process. If we want to have a way to show that upstream is inactive, that is pretty reasonable thing to do.

Yet everyone seems to agree that there are "zombie" packages in the distribution—and that in general they are not desirable. In addition to increasing the clutter in the distribution, zombie packages can become a security liability—either directly, or by prolonging the existence of old versions of libraries and other dependencies.

The difficulty is in finding them, given that a lot of good older packages "just work" and rarely elicit new comments or bug reports from users. Adam Williamson suggested that perhaps there needs to be "an approach which tried to identify software that was truly abandoned either up- or down-stream - not just 'software that no longer required changing' - and throw that out?" As he subsequently clarified, his proposal was that Fedora try to find a way to catch the "easy cases," but so that a person, not an automatic process, would make the decision as to whether a package should be pruned out.

Part of what makes the zombie hunt problematic is that while packages that fail to build (which would be obvious candidates for elimination) are easy to identify, packages that build but do not work right are difficult to find without human intervention. All Fedora packages are automatically rebuilt periodically (in a mass rebuild) to account for important changes like updates in the toolchain, so it is not possible to simply see how long it has been since a package was last built. A bad package could theoretically pass build tests and be automatically included in the archive for years even if it is unusable—if no one uses it, no one will discover that it does not work.

Zbigniew Jędrzejewski-Szmek then offered up a practical suggestion for measuring the abandonment factor of a package. He informally called the idea "bug years," which he defined as the time since the last non-mass-rebuild release multiplied by the number of currently open bugs. Most seemed to agree that the concept had merit—simple enough to understand, while not being subjective. Sundaram suggested compiling a list and bringing the results to the community on the mailing list, thus giving potential maintainers the chance to claim a package rather than automatically dooming it to deletion.

What happens next is still to be determined. Pierre-Yves Chibon ran some queries on Fedora's build history, and found just 60 packages that have not been rebuilt for 200 or more days. That is certainly a manageable number for human volunteers to inspect further, but there is likely to be a process of refinement involved before anything resembling a formal process for locating zombie packages would be created. In the meantime, users will have to remain on the lookout for themselves—but at least the upcoming Software Center in Fedora 22 should be guaranteed a zombie-free zone.

Comments (16 posted)

Brief items

Distribution quotes of the week

The choice of default init system will be decided by a best three out of five set of Dota 2. Better get practicing! :)
-- Russ Allbery

Of course, were the Secretary to choose a four-sided dice, OpenRC proponents might be unhappy. But that's life when entrusted to random.
-- Gunnar Wolf

Even a simple list of packages ordered by the time from last non-mass-rebuild release multiplied by the number of currently open bugs would be quite useful. Packages with bug-years above 50 or so would be good candidates for inspection.
-- Zbigniew Jędrzejewski-Szmek

Comments (none posted)

A call for votes in the Debian init system discussion

Debian Technical Committee chair Bdale Garbee has put out a call for votes on a ballot intended to move the discussion on init systems forward. Rather than vote on the ballot that had been under discussion, though, he is asking a simpler question that, he hopes, will yield a useful answer. "I propose we take the simplest possible 'next step'. Let's vote just on the question of what the default init system for Linux architectures should be in jessie. Once we have an answer to this question, it seems to me that we would be 'over the hump' and more likely to be able to re-focus our attention on all the secondary questions, like what our transition plan should be, whether we should try to dictate a default for non-Linux architectures, how and to what extent alternate init systems should be supported, and so forth. Most importantly, we could start *collaborating* again... which is something I fervently wish for!"

Full Story (comments: 169)

(The first) Debian init system vote concludes

The vote called for by Debian technical committee chair Bdale Garbee has reached its conclusion: the winning option is "further discussion required." The vote was torpedoed by the lack of language saying that the result could be overridden by a simple majority vote by the community on a general resolution. Committee members are working on a new vote now that will have such language, but which will still lack much of the detailed language found in early draft ballots. Stay tuned.

Full Story (comments: 151)

Distribution News

Debian GNU/Linux

Bits from the Release Team: Architecture health check

The Debian release team takes a look at the status of architectures in sid (unstable). Right now amd64, i386, and powerpc ports will be released with Jessie.

Full Story (comments: none)


openSUSE 12.2 has reached end of SUSE support

SUSE sponsored support for openSUSE 12.2 has officially ended. Time to upgrade to 12.3 or 13.1.

Full Story (comments: none)

Ubuntu family

Ubuntu 13.04 (Raring Ringtail) End of Life

Ubuntu 13.04 has reached its end of supported life. The upgrade path is via Ubuntu 13.10.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

McGovern: Valve games for Debian Developers

On the debian-devel-announce mailing list, Neil McGovern has announced that Valve is offering all Debian developers a free subscription to all past and future Valve-produced games on SteamOS. "At $dayjob for Collabora, we've been working with Valve on SteamOS, which is based on Debian. Valve are keen to contribute back to the community, and I'm discussing a couple of ways that they may be able to do that. Immediately though, they've offered a free subscription to any Debian Developer which provides access to all past and future Valve produced games!" He goes on to give details of how to get access to the subscription. The thread on debian-devel is worth checking out as well. (Thanks to Josh Triplett.)

Full Story (comments: 35)

Upstart SolydXK Distro Seeks First Business Customers ( has an interview with SolydXK developer, Arjen Balfoort. "SolydXK is a stable, and secure operating system, and is a viable alternative for small, and medium sized businesses, non-profit organizations, and home users. SolydXK is not hardware intensive, and uses little hardware resources, which makes it suitable for even the older systems in your organization. SolydXK needs to be installed just once throughout the system's live-cycle, and upgrades are thoroughly tested by our testing team, and made available in quarterly periods thus minimizing the risk of breakage to an absolute minimum. Support is given through our community's forum, and this year we'll professionally extend support, and services..."

Comments (none posted)

Page editor: Rebecca Sobol
Next page: Development>>

Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds