The new X11 implementation, has now been put in rawhide (was Re: Xorg server)

Mike A. Harris mharris at
Wed Mar 17 18:51:07 UTC 2004

On Wed, 17 Mar 2004, Sandy Pond wrote:

>So, I noticed the Xorg server on rawhide ... so what's the story.

The short story, is that XFree86 is being replaced by The 
Foundation X11 implementation, which currently includes all of 
the parts of XFree86 4.4.0 which are not affected by the recent 
XFree86 license version 1.1.  For the most part, users won't 
notice the difference between the two X11 implementations for the 
initial release.

>The XFree server is still the default.

We're working on that currently.  Also note that the X 
server has not yet been renamed to it's final name, and that more 
changes are pending as Fedora Core 2 approaches.  I'll be posting 
updates about this over time also.

>Can Xorg server be installed in parallel for testing?

No, it is an all or nothing deal basically.  People either 
continue to use XFree86 4.3.0 and thus not test xorg, so less 
bugs get fixed in the stuff that we will end up shipping, 
or people upgrade wholesale to the new stuff and start 
using it and reporting bugs so we can get it into shape for 
Fedora Core 2.   ;o)

The other option, is for someone else to go and package XFree86 
4.4.0 themselves which the previous posting to this list 
indicates someone has already done.  Note however that we do not 
support 4.4.0, and will not support systems that are using it.

Once has finished churning, there's really no good reason 
to use XFree86 4.4.0 for the majority of people out there anyway, 
so that's not going to be a problem.

At this stage however, it should be noted that the current
xorg-x11 rpm packages that have just been placed into rawhide are
extremely brand new (xorg-x11-, and it
wasn't until about 4am EST last night that I worked out the
majority of the rpm upgrade dependancy issues.  

This morning some more issues were reported internally and I've
fixed them.  The new packages just built as:


There almost certainly will be various problems discovered with 
respect to rpm upgrades, etc. however the packages have now 
reached the point where they are ready for public testing 

I look forward to hearing people's good/bad success/failure 
reports, and any problems that arise being filed in bugzilla with 
as many details as possible.  I recommend that anyone doing the 
upgrade from XFree86 4.3.0 to xorg-x11 by hand, should run:

rpm -qa > rpm-before-xorg.txt

Then after upgrading do:

rpm -qa > rpm-after-xorg.txt

Also, either redirect the output of your rpm upgrade command, or 
apt/yum/up2date into a text file, in case there are errors or 
problems occur.  Be sure to include these logs and/or screenshots 
of the upgrade attempts in your bug reports, as that will help 
very much to fix the dependancy problems that haven't been found 

On the good news side of things, there were only about 23 rpm 
packages in the distribution that needed to be fixed!

Some things I learned in the process:

- Some packages have bogus dependancies on "XFree86-libs" in 
  packages in order to ensure the X libraries are installed.  Do 
  not do this - rpm's find-requires script does this 
  automatically for all packages and in a manner that doesn't 
  hard code the package name needed to supply the libs.

- Some packages have BuildRequires: XFree86-libs instead, or in 
  addition to BuildRequires: XFree86-devel.   Do not do this.  
  Only put the dependancy on XFree86-devel.  The XFree86-devel
  package itself requires XFree86-libs, so there is no need to 
  overstate dependancies, as it just creates problems in times 
  like this.

- Many font related packages Require or BuildRequire 
  "XFree86-xfs", which at one point in time was to ensure 
  mkfontdir is installed.  Don't do this, instead make the 
  dependancy directly on the mkfontdir binary, or simply on 
  "mkfontdir".  I will add a new virtual provides to the package 
  containing mkfontdir to make this easier.

- Some packages had a hard coded dependancy on "XFree86" because 
  it was felt the package should require XFree86 because it was a 
  graphical X11 application or library.  lesstif being an example 
  of a library that did this.  Don't do this, because there 
  really is not a need for the XFree86 package to be installed if 
  only running applications remotely.

Basically, any application that hard codes a dependancy on 
"XFree86-<something>" is about to get burned badly as 
XFree86-<everything> vanishes.  ;o)  In the mean time, I have set 
up some virtual provides in order to minimize problems for the 
immediate future.

All packages which require X development headers, should for the 
time being CONTINUE to BuildRequires: XFree86-devel, as i have 
put a virtual provide in the xorg-x11-devel subpackage of:

Provides: XFree86-devel = 4.4.0

That interim measure should suffice to put out some fires for 

Additionally, I have added new virtual provides to various other 
packages.  If a package needs xdm/twm/base-fonts or other similar 
packages, instead of doing:

Requires: XFree86-xdm   or Requires: xorg-xdm

instead do:

Requires: xdm

That makes it easier for rpm packages out there to work with 
different X11 implementations.  Note that the implementation 
nonspecific virtual provides, are intentionally versionless.  My 
feeling is that, if some application for example requires a 
specific version of xdm/base-fonts/twm or other packages, then it 
is probably an implementation specific requirement rather than a 
generic one, and so such packages should indeed have hard coded 
dependancies on the specific implementation-version instead of 
using the generic dependancies.

Anyhow, that's a brief summary of recent X11 events in the oven.  

I welcome public feedback and comments, preferably to the mailing
list, as I prefer to have feedback be public rather than private,
so that others can further comment as well.

Be sure to leveredge bugzilla also!

Thanks everyone for testing Fedora devel!

Mike A. Harris
OS Systems Engineer - XFree86 maintainer - Red Hat

More information about the fedora-test-list mailing list