[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)

Hash: SHA1

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:
| 	xorg-x11-
| 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!

What about those using nVidia/ATI binary drivers?  What will the
implications be for 3d acceleration?

I just got UT2k4, don't tell me I won't be able to play it under X.org...

- --
- ----------
Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs

Quidquid latine dictum sit, altum viditur
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


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