[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: Doug Stewart <dstewart atl lmco com>
- To: For testers of Fedora Core development releases <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 15:33:23 -0500
-----BEGIN PGP SIGNED MESSAGE-----
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:
| 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!
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...
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
Quidquid latine dictum sit, altum viditur
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
[Date Prev][Date Next] [Thread Prev][Thread Next]