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:
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.
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.
Newsletters and articles of interest
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