Packaging Project

The GNOME Packaging Project is currently basically dormant and has been since the release of the first Ximian Desktops. Since Ximian no longer provides this service to GNOME, it is important for the GNOME Project to again produce packages, both to increase GNOME's QA coverage, and to help show off how cool GNOME is to those folks who like to live on the very cutting edge, but who don't quite want to build from CVS. Because any attempt to resurrect the GPP could be optimistically described as 'nascent', take anything else on this page with a grain of salt. If you want to help out, skip to Communication- we need every able-fingered hacker we can get.

Status

While we don't currently have any packages available directly from GNOME (unless you want GNOME 1.4 for RH 7.0), there is ongoing work by LuisVilla4 to provide a MicroTinder at gnome-build.ximian.com. Unfortunately, that box (as of 3/28) has a busted mobo and is down for the count. But it'll be back in some form or another.

Other Package Sources

If you're looking for packages, and can't wait for the packaging project to resurrect itself from the dead (We're not dead yet!) the following projects are known to provide GNOME binaries for end-users:

• usr-local-bin for SUSE

• Debian GNOME packaging team

• Very Unsupported packages for Fedora Core 2 and 3

• Dropline GNOME for Slackware

• Conary-based distribution shipping the latest GNOME packages as well as some leading-edge technologies like Beagle.

• Unsupported packages for Mandrakelinux Ltd.Ed. 2005, a.k.a. 10.2

• Ubuntu ships the very latest GNOME in its stable and devel branches

Communication

packaging project discussions take place on packaging list. Anyone who is interested in helping out is welcome to drop the list a mail and discuss what skills you have, tasks you'd like to tackle, or favorite flavor of ice cream.

Goals

AKA 'what we really want to do', not to be confused with 'how we want to do it.'

• make it easier for users to file high quality bugs for GNOME QA

• make it easier for users to see and use the latest and greatest so that they have a better sense of GNOME progress and can spread that information, similar to the GnomeLiveCd.

• help developers get a handle on whether or not their code broke the build.

Tasks

These are concrete tasks that implement the goals above. Insert Management Mumbo-Jumbo(tm) Here.

• build daily unstable builds of core gnome stuff on multiple common distros, with some sort of automated build system. This is sort of the Holy Grail, and will require as much build-system hacking as anything else, most likely.
• run a tinderbox reporting constantly on the build status of the whole stack.
• get a gnome build-farm going; initially this would only be beefy x86 hardware on a nice pipe, but would ideally be expandable or better yet distributable, so that the builds/admin for a solaris packaging/tinderbox could happen (say) within sun.com, but with packages and tinderbox data uploaded to gnome.org for distribution.

Resources

• current build systems:

  • jhbuild: custom-fitted for GNOME, but lacks package-building functionality. Has been hacked into MicroTinder.

  • build-buddy: has been used to build all of GNOME in the past on multiple distros and operating systems, and is very powerful, but which very few people have experience with. Some conf files for GNOME snaps using build-buddy are in GNOME CVS already.

• Currently we have no build boxes, but Novell is working on restoring one, and if that falls through at some point, we should be able to procure another one- challenge will be administration and location.

• spec files: some packages have existing spec files, and James Ogley and others have written sets for most of GNOME already, though they are not cross-distro or anything of the sort. Notes on CrossDistroSpecFiles from JamesOgley.

Challenges

• lots of work. Doing even a single build of all of GNOME (including writing all the spec files) is a lot of work. We can tackle this, perhaps, by working on the build system.
• big stack- For example, it is quite possible that GNOME 2.12 might require an XServer newer than the one on most distros. What do we do then?
• disagreements on packaging philosophy- should we replace the distro GNOME, or parallel install? Parallel install has advantages in terms of recoverability, but makes some testing less useful and can hinder the utility of the install (though this is less the case than in the past, given freedesktop standards for things like menus.)