On Mon, Jan 24, 2000 at 07:25:57PM -0800, Mark Montague wrote: > Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes: > > > The easiest way of doing things for now, is to package just the Xserver, > > and stuff related, in a way compatible to 3.3.6 packaging. It is > > possible to use 3.9.x server together with 3.3 other stuff. The X Strike Force page has been updated with the 3.3.6-3 announcement as well as my plans for 3.9.x packaging. > That seems like a good start, although we'll need to get the modules > stuff right, too, so it won't just be one binary. Yes, and there are furthermore several different kinds of module that can be loaded. On top of that, the loadable module architecture makes it possible for modules not originating with XFree86 to be used. So it looks we get a mini-great-X-reorganization again, with new virtual packages, when it comes to the X server. Here's my current thinking on the subject. This is really tentative; I haven't even compiled 3.9.x yet, let alone implemented the packaging. [NOTE: if the following looks weird, your MUA is not rendering tabs correctly] package name Provides notes xfree86-xserver xserver just the core server, will need to depend on a bunch of virtual packages xfree86-driver-tdfx x-server-driver there are going to be lots of these xfree86-rasterizer-pcf x-server-rasterizer there will be several of these, too; freetype, type1, etc. xfree86-glx-mesa x-server-glx GLX implementation [not sure about the details on this] And possibly some others. The bottom line is that lots of stuff is modularizable. xfree86-xserver will likely depend on x-server-driver, probably recommend x-server-rasterizer (remember, folks can use an external font server), and suggest anything else. I'll need to explore things and see what is mandatory for basic X server operation. Alternatively, things might just be named "xfree86-module-*". I'll still need virtual packages for the chipset drivers at least, I think. In any case, I'm going to have to come up with some policy regarding the naming of these things, as I have no intention of trying to keep up with every non-free (or even free) third-party server module for XFree86 4.0. But the policy will need to wait until we're out of the vaporware stage. > Well, I've been testing the xlib stuff, too... there have been some > changes there, and, in particular, the switch from select() to poll() > broke netscape. For the most part, though, I agree with you, and a lot > of what I got stuck on was deciding which debian patches I should or > shouldn't migrate from 3.3.6 to 3.9, and this will reduce a lot of > them (like the debianization of xterm). Before people on this list panic, we should share with them that Keith Packard and others are working to make sure that Xt will continue to support nasty old Netscape even with the migration from select() to poll(). (Actually, I think it is Motif's fault, but I'd have to review the thread on the XFree86 devel list). > > My suggestion (see previous mail on it) would be tyo install the server > > in /usr/X11R6.4 and to maybe patch the server so it reads > > /etc/X11/XF86Config.4 or something such. This way, it would be easy to > > have both server installed and running, without problem. > > The other libs could go into /usr/X11R6.4/lib, and users testing that > could actually put that into their LD_LIBRARY_PATH; that's what I've > been doing, which works except that LD_LIBRARY_PATH is ignored for > setuid programs, which bit me on xterm. I am not planning on supporting multiple installations of X at once. It's going to lead to a rat's nest of problems that I really, really want to avoid. Just managing the transition from 3.3.x to 4.0 is going to be bad enough. In fact, I'd rather not have xfree86 3.3.x and xfree86 4 packages both in the distro at the same time. But I may not have any choice; it depends on how much legacy video hardware is out there, and how much of it can be made to work with the fbdev or generic vga. I forsee great pain. On the other hand, with the x86emu code giving us access to VESA BIOS modes, there is a small glimmer of hope. > I had thought about making /usr/X11R6 a symbolic link to either > /usr/XF366 or /usr/XF3917 or what have you, but enough programs put > things into /usr/X11R6/bin and friends that it would probably be a > pain. Also, people would need to run ldconfig when they swapped the > link. Just thinking about the support issues this would cause is enough to give me a stroke. > I strongly advocate building the server as modules, although I can > imagine some people wanting to have several static servers... I think > we should start with the modular, though (but maybe I'm biased by > having that set up on my machine already...) Yes, I'm strongly slanted towards the modular approach as well. It will cut down on consumed disk space and, I think, make autoselection of the needed driver more straightforward. There is also no reason I can't build and package a "kitchen-sink" emergency X server. Time will tell if that is really necessary. -- G. Branden Robinson | A committee is a life form with six or Debian GNU/Linux | more legs and no brain. branden@ecn.purdue.edu | -- Robert Heinlein roger.ecn.purdue.edu/~branden/ |
Attachment:
pgpy1s6TgXIrZ.pgp
Description: PGP signature