[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: The new X.org X11 implementation, has now been put in rawhide (was Re: Xorg server)
- From: Paul Bender <pbender qualcomm com>
- To: fedora-test-list redhat com
- Subject: Re: The new X.org X11 implementation, has now been put in rawhide (was Re: Xorg server)
- Date: Wed, 17 Mar 2004 14:10:26 -0800
On my system, I upgraded the XFree86 RPMs with the corresponding
xorg-x11*-0.0.6.6-0.0.2004_03_11.5.i386.rpm 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
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-0.0.6.6-0.0.2004_03_11.4), 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
- 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
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
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]