Even if I recently stated I lost some of my faith in XCB, I still sometimes hack things to add support for it. These last days, I've worked on a D-Bus port from Xlib to XCB. The port was quite straight forward, since there's only a little piece of D-Bus using X, which is dbus-launch. I though D-Bus was a good candidate, since it's part of the Freedesktop initiative. Therefore, I was expecting a warm welcome and some enthusiasm from a fellow project. My contribution got one useful review, and a cold reply from Thiago Macieira (a KDE/Qt/Nokia developer):

No, sorry, I don't agree.. I've just checked and my Solaris machine doesn't have XCB. Please do not remove the X11 code. You may add the XCB code, but you cannot remove the X11 code.

This is not really the kind of answer I expected, actually. I then reworked the code to please Thiago, and added some #ifdef to add XCB support to D-Bus, with a fallback to libx11 where XCB would not be available. Havoc Pennington replied:

Given that libX11 now uses xcb as backend, I don't understand the value of porting to use libxcb directly when there isn't an issue of round trips or other stuff. It will just make #ifdef hell, while the X11 API is an API that works on both xcb and non-xcb platforms. Maybe people should be thinking about porting xcb to non-Linux platforms? The X protocol should be the same on other UNiX, so xcb in theory ought to work fine if you just compiled it on Solaris/BSD, same as GTK or dbus or Qt would work fine.

The last part "Maybe people should be thinking about porting xcb to non-Linux platforms?" is still unclear to me, even though I asked Havoc to explain what he meant. Finally, Thiago refused to merge the patch:

[ ] thanks for the patch, but like Havoc I am unsure of the value. We can't drop the X11 codepaths now because too many systems exist without XCB. Adding the XCB codepaths only made it more complex, even though you did a good job.

I can't disagree with that conclusion: using both XCB and X11 make the code unreadable for little gain. That's why I did replace libx11 by XCB directly in the first version of the patch. On the other hand, D-Bus people does not seems to really care about making their software evolve in the right direction, even if that requires users to upgrade their systems. I think D-Bus using and depending on XCB would have been a good point to push adoption of XCB. Unfortunately, it seems you can't even rely of projects of the same initiative (i.e. Freedesktop) to work together to make things a little bit better. After 5 years of existence, XCB is still not so obvious to people, and making it adopt is going to be a challenge for the next years. The upside is that new X.org 7.6 will bring XCB with it, as part of the katamari.

Stage 1 of the new koha installer uses MakeMaker and some silly tricks to try to install a CGI tree, as well as modules. You can often grab prepatches from mjr-installer if you really want the latest bits sooner. The biggest user-visible change with this installer (compared to 2.2) is that it's dumb. It's dumb in that it's trying to do the simplest thing that could possibly work and it's dumb in that it doesn't ask the installing user any questions. If you know you want to change things, you can tell it, but it doesn't ask you to confirm everything like the 2.2 installer did. Almost immediately, that was criticised on IRC. The first criticism was about a related feature that someone else removed earlier in 3.0, really. The second criticism was stalled by the realisation that if we really want an interface that "questions everything" every time, a wrapper script can ask for all the settings and instruct the dumb installer. I'm not sure whether asking users to confirm everything is a good move, for the sort of reasons in Havoc Pennington's 2002 essay under "The Question of Preferences" - each setting we encourage people to change makes it harder to debug installation problems. That's one of the biggest pains with 2.2 and I think we've started seeing the same happening in 3.0 already. It's not quite "no two installations are identical" but it's not far off. So, the main installer defaults everything to the best values that I can guess that will work within the constraints. It should work for most people and it should be easier for packagers to override. I'd still love to hear about how other Perl CGI scripts install, especially if they use MakeMaker for the basics, then use a CGI interface for the rest. Are you writing one?