Don't Trip on the Red Carpet, Evolve with GNOME CVS

A Good Week for Compulsive Updaters

This last week has been a great one for GNOME watchers, and it provided plenty of opportunities for a lot of apt-getting. Last Saturday, GNOME 1.4's first beta release came out. Ximian had it packaged and ready to go in remarkably short time. A few days later, Ximian was at it again,rolling out Red Carpet 0.9, which we'll look at further along in this column.

GNOME 1.4 Beta One: Hold Your Horses and Give it a Week
GNOME 1.4 Beta One provided a lot of people with their first look at the upcoming 1.4 release, including the first chance a lot of people just following along have had to see Eazel's Nautilus running on their machine. There's a lot of interesting stuff to see in the release, but it's a good one to stay away from for the moment unless you're genuinely interested in helping the developers find bugs. I emphasize that last because this is a case where they're making a widespread release to get the word out, get some eyeballs trained on potential problems, and prime Bugzilla with some fodder. They aren't releasing a new stable version you can get work done with, so people approaching it should take stock of whether they want to download it out of a desire to help or a need to have the latest and greatest because it's there.

Sometimes helping out your favorite project by compulsively downloading the latest snapshot or refreshing your copy of the CVS tree of a favorite project is hard. It involves things breaking, or going wrong, or not working as billed, and this particular release is no exception. Though the version of gdm, the GNOME X display manager, that ships with the beta has a "GNOME Classic" option for using GNOME 1.2, there are a lot of core libraries that get updated for this beta, and some things break as a result.

Download this with your eyes open or, better yet, give it another week or two: a second beta that will likely take care of the worst of the bugs unearthed by the more adventurous is supposed to be making its way out in a week (February 28).

Opportunity knocks in the form of a broken library
This brings us around to another issue, preparatory to getting a long-deferred hands-on with Red Carpet, Ximian's package manager, which is the price you sometimes pay for following a lot of cutting-edge projects closely: mangled dependencies. The latest victim of this particular syndrome is Evolution.

Evolution and Red Carpet both depend on the gtkhtml library. Evolution, for instance, uses it in part to render HTML mail and in part for composition of messages. A version of gtkhtml was shipped out that broke elements of the library needed to compose messages in Evolution, leaving a lot of people curious about Red Carpet with a broken mail client to contend with.

By the time this hits the web, there's a chance the snapshots Ximian is shipping will have corrected the problem (they're reportedly moving their servers this week, contributing to a slowdown), but in case it doesn't, this is an excellent opportunity for the curious to learn a little about GNOME CVS, because all that's needed to get both Red Carpet up and running and restore Evolution to proper functionality is a build of gtkhtml from CVS.

The GNOME project has provided a page that teaches a little about how to use anonymous CVS to get the latest elements of the GNOME project. There's no point in replicating all the information that link provides, since it's clear and concise and even I can follow along. The thing to keep in mind is just that in order to have both Red Carpet and Evolution running alongside each other at this point, you want to get a copy of gtkhtml with cvs -z3 checkout gtkhtml once you've set the proper environmental variables. You'll need to build the library and replace the existing gtkhtml once you've installed Red Carpet, because most of the means for obtaining it will automate the installation of the newer, broken version of the library.

Building from CVS, just to provide one more caveat for newer users, isn't the same as building from a tarball. CVS builds involve using the autogen.sh script found in the package's directory and passing appropriate variables to it much as you would with a typical configure script found in source tarballs. In the case of building for GNOME packages, putting new builds in right place is key. You'll likely want to use the line:

./autogen.sh --prefix=/usr --sysconfdir=/etc

if you're building against a GNOME installation you downloaded as binary packages for your distribution.

You can probably install the library over the existing one Red Carpet will install, but if you can, force the removal of the package using either the dpkg -r --force-depends command or RPM's rpm -e --force. Your package manager may complain for a day or two, but it's tidier when it comes time to resync with whoever's providing your binary packages, because you'll be able to simply make uninstall the library you built from CVS and replace it with a normal binary package when the time's right without worry of cruft being left laying around in your directories.