I have been getting a fair amount of mail about this so I thought I would
mail two of the most widely-read lists Debian has. Hopefully folks will
agree with me that XFree86 4.0 support has ramifications for both users and
developers. I don't subscribe to -user, so I will not see replies posted
to that list.
*) What?
In case anyone missed the fanfare, a major new upstream version of XFree86
-- the version of the X Window System Debian uses -- was made last week.
In addition to being based upon the latest official code base of the X
Window System itself, X11R6.4, XFree86 4 features many architectural
changes and enhancements -- far too many to list here. Interested readers
can start with the following two URL's:
http://www.xfree86.org/4.0/README.html
http://www.xfree86.org/4.0/RELNOTES.html
*) Who?
As Debian package maintainer for XFree86, it's my responsibility to come up
with Debian packages. They're not available yet, so I am sending this
message to apprise Debian users my fellow developers of the situation.
That brings us to the question that everybody has been asking...
*) When?
I don't know. I had hoped to get some preliminary packaging done on the
3.9.x (4.0 pre-release) series, but time constraints prevented that from
happening. Furthermore, the 4.0 release doesn't even build out of the box
on Debian[1]. This is a recent breakage; 3.9.18, released just a couple of
weeks previous, compiled fine. But, I'm not resigning my position as
XFree86 package maintainer. Getting 3.3.6 fit for potato is actually
priority number one, but since that is just in a scrutiny cycle for
release-critical bugs, the lion's share of my Debian time is actually going
to XFree86 4.0. I don't have a timeframe on when they'll be ready yet --
the reasons are discussed below.
*) Where?
Phase 1) My initial intention is to make even my earliest progress
available to interested Debian users. These packages will be highly,
HIGHLY experimental, and I will make any effort to support smooth upgrades
between them. This means that I will be maintaining package relationships
only with respect to officially released Debian packages (3.3.6-x and
previous). The practical consequence of this is that it may be necessary
to purge the packages of one of these experimental releases before a new
experimental set can be installed. This is inconvenient, but it is better
than clogging up the Depends/Replaces/Provides/Conflicts/etc. lines with
cruft from an experimental series of packages. These initial experimental
versions will only be available from the official Debian homepage of
XFree86 development, the X Strike Force <http://www.debian.org/~branden/>.
Initially, I probably won't provide a proper APT repository since upgrading
will likely be broken anyway. I will only expect the kind of people who
would build XFree86 4.0 from source themselves to use these packages.
These will not be appropriate for consumption by ordinary users who want
things to "just work". Since these won't be official releases, bug reports
filed with the Debian Bug Tracking System against these packages will be
closed immediately and without comment.
Phase 2) This phase will occur once I've settled upon a package arrangement
and have worked out what I think the most critical issues are going to be,
I'll expand my testing model a little bit. I won't release to unstable,
but I'll make my test packages APT-able. My target audience for this phase
is people who aren't going to panic if things break or work funny. Again,
since these won't be official releases, bug reports filed with the Debian
Bug Tracking System against these packages will be closed immediately and
without comment.
Phase 3) This will happen once I have a fair amount of confidence in the
packages. I will release them to unstable and they will be treated like
any other Debian package in unstable. (At least, as much so as the XFree86
packages ever are.)
*) Why?
Why all this complication? Why a three-phase approach to packaging XFree86
4.0? There are a number of reasons:
1) I'm going to repackage XFree86 basically from scratch. If debhelper
is up to the task -- and I think it is -- I'm going to use it. It
really does nicely automate a lot of the otherwise tedious stuff in
packaging, and I need to focus my energies on the bigger issues. I
will continue to use some form of "Doogie's Build System", which I
think is invaluable for a package of this size.
2) Package relationships are going to be shaken up quite a bit. The
biggest change is the server model, discussed in the Release Notes URL
above. There will be one server binary, "XFree86", which dynamically
loads various server modules for diverse purposes. This will probably
demand a fairly involved virtual package setup, since there will be
various choices available with respect to font rasterizers,
framebuffer layers, chipset-specific drivers, GLX implementations, and
so forth. There are also not insignificant changes like the fact that
xcontrib has been re-absorbed into the official XFree86 source tree,
and that I will probably have to break the Athena widget library out
of xlib6g, because two separate versions of it can be built -- the
X11R6.4 version, and a "7.0" version which has been pioneered by the
guys at XFree86. As a peripheral consequence, this may ease the
nextawg/xaw3dg/xaw95g situation a little bit. Furthermore, libc5
library support on i386 and m68k is going to be dropped. I'm going to
plant my feet and say that no person in his right mind is going to
build libc5-based clients against the R6.4 libraries (or Xaw 7.0), and
even if they do, I won't support them. Before anyone panics, I should
point out that I'm quite amenable to keeping a stripped-down,
library-only 3.3.x source package around for the purpose of building
libc5-linked X11R6.3 client libraries. This will maintain our
backwards compatibility -- it just won't be done in the xfree86 4.0
packages. I'm very likely going to want to spin the libc5 3.3.x
responsibilities off onto someone else. After the initial packaging
is done, these should be very low-maintenance packages.
3) I think XFree86 4.0 is going to take a little while to settle in. Not
everyone is going to want to switch to it immediately. Why? Because
their graphics hardware might not even be supported! See
<http://www.xfree86.org/4.0/Status.html>.
That's it for now. Please be judicious before replying privately; the more
mail I have to read, the less time I have for packaging XFree86 4.0. :)
As I said when I first took over maintainership of the XFree86 Debian
packages two years ago this month, I'm not person best qualified to do this
job from the standpoint of in-depth knowledge of the X Window System; I'm
just the only guy who was crazy enough to volunteer. The good news is, I
know a hell of a lot more now than I did two years ago. I appreciate
everyone's patience and understanding in this process.
[1] The makedepend program gets stuck in an infinite loop when attempting
to generate dependencies in xc/programs/xterm. One of Tom Dickey's
patches, #130 or #131, is probably the culprit since I think these are the
only two changes that happened to the xterm sources between 3.9.18 and 4.0.
--
G. Branden Robinson | Men use thought only to justify their
Debian GNU/Linux | wrong doings, and speech only to conceal
branden@ecn.purdue.edu | their thoughts.
roger.ecn.purdue.edu/~branden/ | -- Voltaire
Attachment:
pgpwy2658rquu.pgp
Description: PGP signature