A 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
management tool are broken because the Fedora Ruby version is too new. One
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
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
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
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
Comments (15 posted)
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
Comments (none posted)
We recently complained
builds based on the Android 4.2 release were not available for most
that CyanogenMod lacked features found in stock Android builds. So it
seems only fair to point out that the CyanogenMod nightly builds page
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.)
Comments (7 posted)
IPFire 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.
Full Story (comments: none)
The 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!
Comments (2 posted)
A 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
Full Story (comments: none)
The openSUSE Board election is over. Raymond Wooninck (tittiacoke) and
Robert Schweikert (robjo) will join the board on the January 9 transitional
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
Univention has released version 3.1
of its Univention Corporate Server
(UCS). The H takes
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.
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>