What distros/flavours provide modular X.org?

Mike A. Harris mharris at mharris.ca
Sun Jan 1 01:48:28 PST 2006


Jeremy C. Reed wrote:
> (I carbon-copied this to two lists. Maybe consider only replying back to 
> the x-packagers list.)
> 
> What Unix/Linux/Other Vendors' distributions or flavours provide modular 
> X.org?

The following Red Hat distributions shipped X.Org:

Fedora devel (will become 5)	X.Org X11 7.0 modular
Fedora Core 4			X.Org X11 6.8.2
Fedora Core 3			X.Org X11 6.8.0 (6.8.2 via update)
Fedora Core 2			X.Org X11 6.7.0

Red Hat Enterprise Linux 4	X.Org X11 6.8.2 (current update release)


The following Red Hat distros shipped XFree86:

Fedora Core 1			XFree86 4.3.0

Red Hat Enterprise Linux 3	XFree86 4.3.0
Red Hat Enterprise Linux 2.1	XFree86 4.1.0

Red Hat Linux 9			XFree86 4.3.0
Red Hat Linux 8			XFree86 4.2.1
Red Hat Linux 7.3		XFree86 4.2.1, 3.3.6a
Red Hat Linux 7.2		XFree86 4.1.0, 3.3.6a
Red Hat Linux 7.1		XFree86 4.0.2, 3.3.6a (4.1.0 via update)
Red Hat Linux 7.0		XFree86 4.0.1, 3.3.6a
Red Hat Linux 6.2		XFree86 3.3.6a

That's a rough list from memory.  The version's listed are pretty
accurate I believe as far as the final X release included in updates
for each distro.  Where that differed from the version that shipped
with the OS, I've added comments in brackets.  You might want to
verify all of the above to be 100% accurate as I'm just going from
memory, but I'm likely 99.99% accurate.  ;o)

For OS releases earlier than what's listed above, my memory banks
seem to have offloaded to offline storage to make room for newer
data.  ;o)

Hope this helps fill your list.

> Does x.org or freedesktop.org have a wiki page that lists them? I'd be 
> interested in taking the results of the replies and putting into the 
> wiki. (What page should I use or create?)

Sounds like a nice historical nostalgia'ish sort of page.  I'm sure
it'd be useful to people.

> Does it also provide monolithic X.org (or XFree86) as an alternative? if 
> so, what is the default and are they interchangeable (without having to 
> reinstall all X-using packages)?

All Red Hat OS releases mentioned above, shipped with either XFree86
or X.Org X11, but not both.  Each Red Hat Linux 7.x series distro
shipped with the current stable XFree86 4.x release at the time, plus
the 3.3.6 series of X servers for compatibility with older hardware.

When we transitioned from XFree86 4.3.0 to X.Org X11 6.7.0, even though
we did not ship XFree86 as an alternative, I updated our packaging to
attempt to keep things X implementation neutral, as I felt that was
a smart thing to do.  In theory, this would make it easy for someone to
create rpm packages of newer XFree86 releases for any of our OS releases
if desired, and if they used the same "virtual provides" as I put in our
X.Org packaging, their XFree86 packages would theoretically be a drop-in
replacement.

I'm not aware of any 3rd party packaging of XFree86 4.4.0 or newer for
Fedora Core 2 or newer or for RHEL 4, but it is at least theoretically
possible to whip up such rpm packages.  This assumes that other packages
in the OS are properly using the virtual provides that are present in
our Xorg packaging, and not explicitly depending on xorg-x11 packages
of course.

One other potential issue however, are X clients or system libraries
linking to newer libraries which are only present in the X.Org
distribution.  A number of new X extensions are present in X.Org, which
may or may not be present in the current XFree86 releases, depending
on wether XFree86.org has integrated newer X bits into their tree or
not.  Apps/libs that are well written should check for the existance
of extensions at runtime, and modify their runtime behaviour based on
wether things are present or not, however there very well might be
apps/libs that are written poorly and have hard coded dependencies on
things which might only be provided by X.Org (or XFree86 for that
matter).

So, "in theory" at least, it is doable to produce XFree86 packages which
should drop into our distro, but wether it works in practice or not,
can only be determined if someone creates such packages.  ;o)  If
someone does however, if any unnecessary dependencies on X.Org exist
in our packaging that can be easily changed in a compatible manner,
please file bug reports in our bugzilla with your findings, and be sure
to CC me on them, and I'll have a look.


> If not in the distro yet, is it expected in upcoming release? When?

We currently ship a single X implementation in our distro currently,
and for the time being at least, will probably keep things this way
for now.  In the mean time, if there is any interest in the community
to package and ship alternative X implementations (xserver/kdrive,
XFree86, Xephyr, Xouvert, etc.) in 3rd party addon/alternative rpm
repositories, it's certainly possible.  With the current modular X.Org
packaging in Fedora development, it's actually much much easier in
fact to swap out various individual components of the system even.  Not
that I would encourage that mind you, but it's possible.  ;o)


> Are all the individual components as provided by X.org as seperate files 
> provided as separate packages (one-to-one)? If not (like one package 
> covers multiple X.org components), why?

Our monolithic X packaging spits out up to 26 rpm packages or so
roughly.  I wouldn't recommend swapping out these packages with
an alternative implementation of the same thing, however replacing
the entire monolithic X tree with another tree is theoretically
doable, but also not really recommended.  With Fedora development,
and the switchover to modular X11R7, it becomes much easier to
upgrade/swap individual components if desired, although it's
still recommended to use the components that ship with the OS.

Some of the modular X components we are shipping in individual
rpm packages, such as the drivers, libraries, and a few other
things.  Other stuff we have grouped into aggregate packages
for various reasons that make distribution maintenance simpler,
and other factors.  Finer grained discussion of that is probably
best moved to a Fedora mailing list tho if desired, as it is more
distribution centric than X.org centric.


> One reason, why I am asking this is I am curious to see what one line 
> descriptions and paragragh descriptions are used for the various 
> packages by different vendors. (I'd like to help get the empty READMEs 
> with some useful content.)

Our package descriptions for modular X are pretty simple and
straightforward currently.  Perhaps even a bit boring.  ;o)

Most of them are simple straight-to-the-point one liners, such as
"libXfoo runtime libraries" or "libXfoo development environment" or
similar.

Hope this info is useful for your wiki pages and whatnot.  If you have
any additional questions for the Wiki about Red Hat X packaging, I'd be
happy to try to answer also.

Take care, and Happy New Year!


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.


More information about the xorg-modular mailing list