The ability to fork a project is one of the fundamental freedoms that come
with free software. If a software project is heading in a direction that
is less than ideal for its users or developers, a competing version can be
created and managed in a more useful manner. Forking has been used to
great effect with projects like Emacs, GCC, OpenOffice.org, and XFree86.
The most successful forks have specific goals in mind and tend to attract
at least a significant subset of the original project's developers. Other
types of forks face a harder road. Arguably, a recently launched fork of
utility under the aegis of the Gentoo project is of the
On November 13, the Gentoo council met to discuss, among other things, how
to support systems that are configured with the /usr directory on
a separate partition. The meeting minutes
show that much of the discussion centered around a new udev fork that, it
was hoped, might help to solve this problem. The existence of a new udev
fork (now called eudev)
within the Gentoo project took some developers by surprise, especially when
the associated README file was observed to claim that it was a "Gentoo
sponsored" project. This surprise led Greg Kroah-Hartman (a longtime
Gentoo developer) to ask what the goals of
the fork were. Getting an answer to that question turned out to be harder
that one might have expected.
One of the developers behind eudev is Richard Yao; his response really needs to be read in its
If we were using the waterfall model, I could outline some very
nice long term goals for you, but we are doing AGILE development,
so long term goals have not been well defined. Some short term
goals have been defined, but I imagine that you are already
familiar with them.
After extensive discussion with a lengthy digression on copyright law (the
eudev developers removed some copyright notices in a way that drew
objections), some of the project's motivations came into a bit of focus.
Part of the problem is certainly the increased integration between udev and
systemd. Udev is still easily built as a standalone binary, but some
people worry that this situation might change in the future; mere
association with systemd seems to be enough to provoke a response in some
That response carries over to the ongoing unhappiness over the deprecation of
/usr on a separate partition. The developers involved claim that
this configuration has not been supported for years and cannot be counted
on to work. In truth, though, it does work for a lot of people, and those
people are feeling like they are having a useful option taken away from
them. Whether a fork like eudev can address those concerns remains to be seen.
Beyond that, a recent switch to the "kmod" library for
the loading of kernel modules has created a certain amount of irritation;
out that feature is one the first changes made by the eudev
developers. Udev uses kmod for a reason: avoiding modprobe calls
speeds the bootstrap process considerably. But Gentoo developers like fine
control over their systems, and some of them want to use that control to
exclude kmod, which they see as unnecessary bloat or even a potential
security problem. If udev requires kmod, that desire is thwarted, so the
change has to come out.
There was also some discontent over the firmware loading difficulties caused by a udev
change earlier this year. That problem has since been fixed; indeed, it
has been fixed twice: once by loading firmware directly from the kernel,
and once in udev. But some developers have not forgotten the incident and
feel that the current udev maintainers cannot be trusted.
In truth, a bit of concern is understandable. The eudev developers point
to statements like this
one from Lennart Poettering:
Yes, udev on non-systemd systems is in our eyes a dead end, in case
you haven't noticed it yet. I am looking forward to the day when we
can drop that support entirely.
After reading that, it is natural to wonder if the current udev maintainers
can truly be trusted to look after the interests of users who do not plan
to switch to systemd. From there, it is not too hard to imagine maintaining
a fork of udev as an "insurance policy"
against misbehavior in the future.
That said, a better insurance policy might be to establish oneself as a
participating and respected member of the current systemd/udev development
community. The strong personalities found there notwithstanding, it is an
active community with developers representing a number of distributions. A
developer who can work within that group should be able to represent the
interests of a distribution like Gentoo nicely while avoiding the costs of
maintaining a fork of a crucial utility. And, should that strategy fail,
creating a fork of udev remains an option in the future.
But nobody can tell free software developers what they can or cannot work
on, and nobody is trying to tell the eudev developers that creating their
own udev fork is wrong. The situation becomes a bit less clear, though, if
eudev is destined to replace udev within Gentoo itself; then Gentoo users
may well find they have an opinion on the matter. For now, no such
replacement has happened. If it begins to look like that situation could
change, one can imagine that the resulting discussion in the Gentoo
community will be long and entertaining.
to post comments)