[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On my system, I upgraded the XFree86 RPMs with the corresponding xorg-x11*- RPMs. In the process, I had a few problems getting them to install and start.

(1) openoffice.org-1.1.0-30 had a dependency problem on XFree86. I got past this by removing openoffice.org.
(2) xauth could not find libXmuu and xinit could not find libX11. I got past this by adding /usr/X11R6/lib to /etc/ld.so.conf and running ldconfig.
(3) xfs did not start automatically. I got past this by running "xfs -droppriv -daemon" manually.

After that it started.

Mike A. Harris wrote:
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 X.org 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.org 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 X.org stuff that we will end up shipping, or people upgrade wholesale to the new X.org 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 X.org 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 consumption.

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 yet.

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 now.

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!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]