LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora ponders Software CollectionsA feature in Red Hat Enterprise Linux (RHEL) that supports multiple, parallel installations of programming languages and other normally system-wide tools was recently discussed on the fedora-devel mailing list. Matthew Miller, who recently started as the Fedora cloud architect, raised the idea of bringing Software Collections from RHEL to Fedora. The idea behind Software Collections is interesting, but no clear consensus on how appropriate they might be for Fedora emerged. As with many Fedora discussions of late, this one at least partly comes back to the question of the role that the distribution is meant to fill. The problem that Miller initially presented is particularly acute in the Ruby and Java worlds, though Python and other tools (e.g. databases) sometimes suffer from it as well. Various packages may depend on different versions of the underlying tools, which makes it difficult to have them coexist on the same system. As an example he noted that the Fedora packages for the Puppet configuration management tool are broken because the Fedora Ruby version is too new. One way to solve that problem is to have multiple Ruby versions available that can be installed in parallel and chosen at runtime. That's exactly the problem that Software Collections sets out to solve. A Software Collection (SC) uses the same packaging tools (RPM, Yum) already used by RHEL and Fedora, but installs the packages and their dependencies in the /opt/provider hierarchy. The provider piece is a specific string assigned to a vendor, which will allow multiple software providers to share the hierarchy without name collisions. There is also an scl tool that allows choosing one or more SCs to be active when running a specific command. Whatever is needed in the environment for the particular SC will be set up by "scriptlets" that get installed with the collection and are run when the SC is selected. As Miller notes, there is nothing inherent in Java or Ruby that leads to version-mismatch problems, instead they are caused by the expectations of developers building software using those languages. There is a strong preference for bundling various toolkits and libraries with such packages, which runs counter to the way Fedora and many other distributions do things. Red Hat Eclipse team member Alexander Kurtakov put it more bluntly:
As a Java guy I'm more and more sure that the problem is not in the
packaging view but in the wrong view of developers not being capable of
making an application if they don't bundle everything. You're [right] the
problem is not in the languages it's in the developers :(.
But, the fast-paced nature of Fedora (normally a release every six months or so) may not make for a good match with SCs. Former Fedora project leader Jared Smith was a bit skeptical about the fit:
Given the short shelf-life of a Fedora release and the complication
involved in Software Collections, I'm still not convinced that we
really need this in Fedora. Can you give me a concrete case where
Fedora really needs to be running two different versions of the same
software, in a production environment? Given it's longer shelf life
and different target audience, RHEL is a better candidate -- and [for] the
record, the company I work for uses Software Collections that way.
I'm just having a hard time justifying it in my mind for Fedora.
Miller had a ready answer. He outlined three separate uses he saw for SCs in Fedora, starting with handling problems like the Puppet issue. Allowing multiple languages would give more choices for Fedora as a development platform. He also noted that RHEL and Fedora make up an ecosystem where developers targeting the former may well be developing on the latter. Access to SCs on Fedora might be quite useful since they are available for RHEL. Those two potential use cases did not require too much discussion, but the other one did:
On a long-lived platform, Software Collections can provide a way to move
faster than the base. On a fast-moving platform like Fedora, we could use
it in the other way: providing longer-lived versions of certain
components even as the base is upgraded.
Bill Nottingham responded with a self-proclaimed "heretical" suggestion that Fedora be turned into a much smaller platform, with packages from the "grand Fedora universe" that target one or more of those platform releases. In that model, the enormous pile of software that Fedora deals with for each release would be greatly reduced. Miller and others—notably enterprise-leaning participants—looked favorably on the heresy, but it was recognized that it would be a difficult direction for Fedora to take. There are, of course, downsides to managing software via SCs. The "library bundling problem" comes to mind, for example. If multiple SCs all include a library (or other component) that needs to be upgraded for security reasons, it may require a great deal of work. One could imagine several different vulnerable versions of a library lurking in SCs that are still being used. Each of those needs to be fixed and all of the SCs need to be updated. For RHEL, that's par for the course, but Fedora has generally moves on before those kinds of problems become acute. The conversation soon pivoted from Nottingham's suggestion to whether SCs might help external projects or companies in making their software available for Fedora. By providing a stable platform and a way for those entities to bundle up and install all of the needed pieces, more software might be made available for Fedora. Much of that software is, of course, proprietary, but there are advocates for making Fedora an easier target for those kinds of applications. One of the problems that Fedora has faced over the years is the explosion of packages that it tries to maintain, test, and release in a short six-month time frame. Several commenters pointed to SCs (or something like them) as a way to decouple Fedora from that enormous list of packages. Projects could target Fedora, without actually becoming part of Fedora, as Fenando Nasser suggested. Those kinds of ideas hearken back to an earlier arrangement for the Fedora distribution. While Adam Williamson's humorous idea of a return to Fedora Core and Fedora Extras was not taken seriously, some kind of similar split seemed to gain quite a bit of traction in the discussion. Whether it goes any further than that down the road remains to be seen, but SCs could potentially help the process if it does. There are logistical and licensing questions—along with plenty of others—that would have to be resolved, of course. If there were a split, how would non-core (for lack of a better term) components manage their SCs and repositories? If they were under the Fedora umbrella, the distribution would have some responsibility for the contents of the packages. If they were not under the umbrella, users would have to somehow enter those repositories into their Yum configuration. Richard Jones outlined a number of issues that would need to be resolved under such a system. While the conversation veered in a direction that Miller may not have expected, it does give an interesting view into the thinking of some (many?) in the Fedora development community. Some of the interest in a fairly radical change may come from frustration with the delays in the Fedora 18 cycle, but there seems to be more to it than that. For some time now, Fedora has been trying to find (or define) its niche. This conversation is another step along that path.
Brief items Distribution quotes of the week
One person's "corner case" is another person's default operating mode.
-- Greg Kroah-Hartman
Before anyone says to use a news item, let me say that publishing a news
item to inform users that we decided to break their systems will not
make it better.
-- Richard Yao
CyanogenMod 10.1 nightly builds availableWe recently complained that CyanogenMod builds based on the Android 4.2 release were not available for most devices, meaning that CyanogenMod lacked features found in stock Android builds. So it seems only fair to point out that the CyanogenMod nightly builds page now includes CM10.1-based (and, thus, Android 4.2-based) builds for a wide variety of targets. CM10.1 works well on the Nexus 7 tablet, with no real problems found so far.(Just be sure to install updated Google Apps as well or things will not go well...not that your editor would ever make such a mistake.)
IPFire 2.11 - Core Update 65IPFire 2.11 core update 65 will be the last release in the 2.x series. IPFire is a hardened Linux appliance distribution designed for use as a firewall. New features include a GUI to configure OpenVPN roadwarrior clients individually and OpenVPN path MTU discovery.
PC-BSD 9.1 Now AvailableThe PC-BSD team has announced that PC-BSD 9.1 is now available. "This release includes many exciting new features and enhancements, such as a vastly improved system installer, ZFS “Boot Environment” support, TrueOS (A FreeBSD based server with additional power-user utilities), and much more!"
Distribution News Fedora Fedora Project OpenID Security issueA bug was discovered in the Fedora Project OpenID provider on December 12. The bug was pulled in with a fix on October 23 and patched December 12, shortly after its discovery. "While the bug was present, anyone with a valid Fedora Account System (FAS) account who tried to log into a remote website using any FAS OpenID identity would have that identity validated by FAS even if the identity belonged to a *different FAS user*. The fix we put in place rejects the attempt if the user who logs in does not own the identity that they requested." Potentially affected accounts have been notified.
openSUSE The New 2013 openSUSE Board MembersThe openSUSE Board election is over. Raymond Wooninck (tittiacoke) and Robert Schweikert (robjo) will join the board on the January 9 transitional meeting.
Newsletters and articles of interest Distribution newsletters
Univention Corporate Server 3.1 with Active Directory functionality (The H)Univention has released version 3.1 of its Univention Corporate Server (UCS). The H takes a look at this release. "The server distribution offers Active-Directory-compatible domain services using Samba 4. The new Univention App Centre simplifies the installation of third-party products such as groupware, document management and backup solutions; the app catalogue provides an overview of available applications."
Page editor: Rebecca Sobol |
|||||||||||||