RFC: X.Org X11 modularization project - rpm package driver naming

Mike A. Harris mharris at redhat.com
Fri Aug 26 22:48:55 UTC 2005


Overview:
~~~~~~~~
We have begun work on X.Org X11 modularization, and are in the process
of packaging the video and input drivers.  Upstream, each driver has
its own individual tarball, which are available at:

http://xorg.freedesktop.org/X11R7.0-RC0/driver

One of the benefits of the modularized X.Org X11R7, is that it makes
it much easier for us to provide individual driver updates without
having to release the entire 150Mb monolithic X release.

The ability for us to update a single driver, and release that
single driver to users is an important thing for a modern OS, in
particular for desktop systems.

As such, we have decided to package each driver individually in its
own src.rpm package.  It has now come to the time where we must
make a decision as to how the driver src.rpm packages will be
named, so we can begin packaging them, and also let the installer
team and other groups know what they're called.  As such we are
soliciting feedback from the Fedora community, including Red Hat
developers and subsystem maintainers.

Proposal:
~~~~~~~~
Here is my initial proposal for naming the src.rpms, along with
brief rationale, and the real (or perceived) advantages and
disadvantages:

xorg-x11-driver-<type>-<name>

The prefix of "xorg-x11" identifies the driver package as being
an official part of the upstream X.Org project.  This distinguishes
the driver from one that might be provided by the "dri" project,
the "gatos" project, or any other project.  It makes it easier
to substitute alternative driver packages that provide a driver
of the same name.  It also makes it clear to the user, the
developer, and anyone else looking at the package, that the source
code contained inside came from X.Org directly.  It also makes
it clearer where bug reports should be filed upstream.  As such,
I propose all driver packages start with the "xorg-x11-" prefix.

The "driver" portion of the proposed name, indicates that it is
a driver for the X server, much like "module" in kernel-module
packages.  It namespaces all drivers, so that they all appear
together in directory listings, and are easy to group together
from scripts using globs, etc.  ie:

# Install all of the xorg drivers:
rpm -ivh xorg-x11-driver-*.rpm

The "<type>" attribute is either "video" or "input", as used
in the upstream tarball names, and further namespaces things,
so that all input drivers appear together, and all video
drivers appear together.  This makes it easy to handle all
input drivers or all video drivers from a script as well.

Finally, the driver <name> field, is the official name of the
driver from the upstream tarballs, which generally is the
name of the driver binary that gets installed as well.

Using this naming mechanism, I believe gives us the most
flexibility with driver packages, and makes life a lot easier
down the line as far as maintenance goes.  It also makes the
packages very obvious as to what their contents are.

The only slight disadvantage to this naming scheme that
comes to mind which someone might point out, is that the
package names are semi-lengthy.  I don't see this as a
problem however, as all modern shells have filename completion,
and it works quite well.  The benefits of clarity of
contents, directory listing grouping, CVS repository grouping,
bugzilla grouping, etc., IMHO far outweigh any perceived
disadvantages of lenthy names.

Request for comments:
~~~~~~~~~~~~~~~~~~~~
Interested Fedora Core, Fedora Extras, or community developers
who have an opinion about the X.Org modular package naming
conventions, or who just want to provide feedback concerning
the above proposal, are encouraged to respond to this RFC on
or before Monday August 29th if possible.

We look forward to hearing everyone's feedback, and incorporating
the collective concious of the community into our decision
making efforts.

Thanks for your considerations.


--
Mike A. Harris
Red Hat Canada, Ltd.
X Devel Team




More information about the fedora-devel-list mailing list