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

[Paul Bender]

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 
> 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-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:
> 
> 	xorg-x11-0.0.6.6-0.0.2004_03_11.5.src.rpm
> 
> 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!
>