Fedora engineering manager Tom "spot" Callaway, who actively maintains a
Fedora-compatible package repository for the Chromium
web browser, said Friday he has "given
up" on getting the browser — which does
work well on Fedora — into the distribution
proper. In November 2009, he explained
why Chromium is not an official Fedora package on his blog, and those
issues remain. In a talk at the Southern
California Linux Expo (SCALE) entitled, "This
is why you FAIL," Callaway, who maintains more
than 350 packages in Fedora, listed some of what he
sees as "points of FAIL," or distribution-unfriendly
software development practices, using Chromium as an
example for many of them.
"Having your software be distribution-friendly
is a key to success," he said. In the Fedora
Activity Day event earlier at SCALE,
users brought in systems in a variety of "states
of disrepair", he said, which were caused by attempting to install
third-party software. Distribution-friendliness also
reflects on other channels, he said. The same "points
of FAIL" that affect distribution maintainers are also
problems for intermediaries who are putting the software on
embedded devices or running it as a hosted service.
In the talk, which summarized his chapter, "How
to tell if a FLOSS project is doomed to FAIL"
from the book The Open Source
Callaway discussed the bundled dependency problem.
It's worth FAIL points to include a private
copy of a library on which a program depends,
and extra FAIL points for building a modified
version. A key problem, Callaway said, is that
when a distribution does a security update for a
library, it also has to do updates for any packages
that include their own copies. (Fedora has a No
Bundled Libraries policy, and Fedora package
maintainers do modify the build process for software that the distribution
packages, in order to make it build with a system copy of the library.)
is perhaps the worst offender I have ever seen in my
entire career," Callaway said.
Chromium developer Evan
Martin, who was not
at the event but had posted
a list of third-party code distributed with
Chromium on his
blog, replied to
that in email:
Briefly, it's a lot of extra
work to support system libraries. With a few more
years of experience on it, I now see the pain of
finding cases where there's been a bug or missing
API in a system library or software, we've fixed
the bug (and even contributed it upstream), but
because distros are so slow to push out updates
our users will be stuck with the old version.
Like in his example in his [Callaway's] post with sqlite, the
fact is that the additional sqlite API can take
months to cycle out to real users' computers,
which doesn't help us much.
Callaway did recognize that some versions of
system libraries might not work. The build process
should make the system copy the default, though.
If the build configuration comes up with "I found this
library and I can't use it because it has rabies or
something," then it could build an alternate copy.
Martin said that the Chromium team is willing to
accept outside contributions to facilitate this:
We have some contributors
from the open source world who write patches for
things like this, so if they write a good patch
we'll accept it. With some libraries we've had to
switch between system and non-system as the Chrome
versions of the libraries skew.
Chromium requires a copyright assignment agreement for
code changes, which Callaway said he has not accepted.
"After review with
a lawyer, they advised me that agreeing to that
would give Google a license to use my contributions
under any copyright license terms that they'd like,
including non-free terms," he said later. "I'd be
more than willing to give them my changes under the
terms of a Free license, but Google wants to continue
to distribute a proprietary version of their browser
(Google Chrome), and I have no interest whatsoever
in helping them with that effort," he added.
Much of the advice in Callaway's talk applied not
to large-scale projects like Chromium, but to new,
lower-profile projects. He reserved some of the
FAIL warnings for projects that don't offer basic
documentation, such as how to do a build and how to
begin interacting with the source control system.
"Lots of programmers coming through school have never
seen a source control system," he said. A project
web site should include instructions for how to check
out the code and how the project wants to receive incoming
code changes. It also counts for substantial FAIL if
"all your web site has is a picture of a marijuana
leaf," as he said one small-scale open source project does.
The build and install process is another key
area. "If your code forces an install into /opt or
/usr/local you're probably running Oracle and I'm
very very sorry," he said. Running "make install"
should just work. "Make the decision that you're
going to have an installable program that works
outside the source directory."
Some software comes in a problematic archive format;
RAR archives are a problem, he said, because the
format is proprietary. A developer once asked
Callaway about making Fedora packages for his new
archiving tool, which came in an archive created
by the same tool. "He didn't see why this was a
problem and I couldn't tell him because I was crying,"
A history of having been proprietary is worth
more fail the longer it was proprietary before the
initial open source release. "Red Hat has bought
some real shiny turds," he said, giving Netscape's
email server as an example. "We buried it in the
backyard," he said.
The good news is that many of the points of FAIL
are relatively easy to correct. Including a copy of
the software license and setting up a mailing list
are minor tasks. The bundled dependency problem,
on the other hand, has turned out to require lots of
skilled attention from both the project maintainers
and distributions, so that one is still with us.
Both library-bundlers and library-splitters have
their points. Bundling creates more long-term
issues for administrators, but library-splitting
takes up valuable development time, especially for
cross-platform projects that need to bundle the
libraries for target platforms that don't
practice library splitting. But bundled libraries are a problem for many
Linux distributions and one that we will
likely be facing for some time to come.
to post comments)