On Fri, Jun 18, 2004 at 10:34:09AM -0700, Keith Packard wrote: > Mostly I'd like to see reasonably small packages which are updated and > maintained separately so that we don't continue to have an over-arching 'X > version' and instead have several distinct X server packages and a single > library package for each (group of) libraries and headers. > > The current monolithic release mechanism isn't helping anyone out. I heartily agree. > I'd also like to see the fonts moved to arch any, I got side tracked > attempting to switch from .pcf.gz to .ttf format, but there's no reason we > can't simply compile to .pcf.gz on i386 and ship them from there -- every > arch can load that format and the overhead is minimal (bitswapping on > big-endian boxes). When upstream moves to .ttf, we will be ready. Uh, well, the fonts are already architecture "all", which means they really are only compiled "once", at least from the perspective of the packaging system. The first architecture's package upload for each release, done by the X Strike Force, contains them. The remaining architectures build them, yes, but they don't ship them. So which endianness the PCF fonts are really depends on what architecture did that initial upload. When Fabio does it, it's x86, so they're little-endian. When I do it, it's PowerPC, so they're big-endian. No one has ever complained of bad PCF font performance as a result of this rather ad hoc approach. (If it matters for any of Debian's supported architectures, it matters for m68k, which are our slowest machines, and which are big-endian. So there's an argument, if a feeble one, for adopting a policy of big-endian PCFs...assuming we need a policy at all. We've gotten along fine so far without one.) So, de facto, we already do exactly as you advise. We do waste time building the fonts (as in, wasted buildd time) on n-1 architectures, but Fabio is doing work on an SVN branch[1] to rectify that. > > * Should we regard X.Org or FreeDesktop.Org as our upstream source? > > I'd like to consider X.Org as upstream for libraries and headers; however, > I'd also like to wait until X.Org has managed to switch to a modular build > system so that the monolithic release problem can be solved easily. From my perspective, we're not in a big hurry. I think changing Debian's shipping sample implementation at this point, when we're -- err -- "about to release" would be a bad idea. However, saying "we're not in a big hurry" is the sort of thing that gets me slandered by certain folks on the mailing lists, so I might as well apologize now for saying it. > For X servers, I think we should have a virtual package so that we can > (eventually) allow people to package many different X servers. We already do; it's called "xserver". > The XSF should support only a single X server using the "standard" DDX > for now. With a virtual package, someone could package up kdrive X > servers and let people use them on smaller systems. kdrive has already been ITPed[2] by Daniel Stone, so I presume it's his Intention to Package it. > > * Should we go our own way starting from the "sanitized" XFree86 CVS > > snapshot we've prepared? > > No, this way madness lies. However, I think we should make sure we > understand where license issues exist in the upstream source; if that > source is distributed in small pieces, we can correctly mark pieces > incompatible with the GPL and get them fixed. I've shared my own observations on these points with the freedesktop.org release wranglers list and X.Org Foundation list. We seem to be missing someone to take action, and in the case of commits cloned between XFree86 CVS and X.Org CVS, I haven't yet seen acknowledgment that there is a problem (or enough information to rule out a problem) from the person who did it. This has given me the impression that the matters I've raised aren't a priority. It would be nice to be taken seriously instead, especially given that most of the community has sent a very loud and strong message that "yes, Virginia, license issues *are* important". I do hasten to add that I'd appreciate your advice in communicating these things more effectively. I know they've been seen and read. What I don't know is why there isn't a fire under anyone to get them resolved. Maybe the fire should be under me? Would I be useful to freedesktop.org as a one-man license gestapo? (I do acknowledge that you've given me access to X.Org CVS and that I haven't done anything with it. Maybe I just need a nudge?) > > * Should we ensure that multiple implementations of the X Window System > > are packaged, or standardize on just one? > > For libraries and clients, we need to have just one implementation. For X > servers, we should permit but not provide multiple implementations. Agreed. > > * If we standardize on just one, which one should it be? > > Each package should come from the canonical upstream source, not some > repackaged distribution. Heh, well, deciding who's "canonical" these days is the real trick, isn't it? :) > For libraries and clients which have multiple 'upstream sources', we need > to pick one; I am going to push X.Org to provide reasonable modular > upstream packages for the core protocol libaries and headers, and separate > packages for the basic X clients which aren't maintained outside. Regarding the latter (xc/programs), the *only* things I know of which *are* maintained outside are the X server itself, XTerm, and maybe luit. > The work at in the xserver and xlibs projects at freedesktop.org can be > considered a prototype for how a modular X project might work; I'm hoping > to get all of that sorted out this summer with X.Org. Excellent. Do you think there's any cause for concern with regards to gray-area X servers like Xvfb and Xnest? I'm thinking of issues like divergent extension support between users of XFree86 4.4.0 and later and, well, the rest of the world. OTOH, maybe the only thing that can be done for users of XFree86 4.4.0 and later is to write a transition guide to help them migrate. Thanks a lot for your response! [1] svn://necrotic.deadbeast.net/xfree86/people/fabbione/trunk/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220345 -- G. Branden Robinson | Debian GNU/Linux | If encryption is outlawed, only branden@debian.org | outlaws will @goH7Ok=<q4fDj]Kz?. http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature