GNOME has launched a binary packaging project headed up by
Gregory LeBlanc. Designed to help users test upcoming beta releases
of GNOME 2.0, the project will initially focus on providing RPM’s
and Debian packages.
The project homepage is located at http://developer.gnome.org/projects/gpp/,
and the
initial request for comments by LeBlanc sites five initial
goals:
- First and foremost reason is so we can do better beta testing. I have a P-III 800MHz computer, with 256MB of ram as my desktop machine. I cannot compile the GNOME 1.4 release in less than a full day on this machine, and I'm very familiar with how to compile these packages. We lose 1 day per beta tester if they have to compile from scratch, which adds up very quickly. More time than that gets lost if they have any compile problems, or a slower machine (think how that would feel on Telsa's "Almost a Pentium" 266MHz computer). We also lose a great many potential beta testers (and probably users) because they just don't have time to compile all of GNOME. - Second, we need examples of how we'd like things packaged. They should show how to break things into different packages for "user only" vs "developer" packages. Maintained packages will help out the distributions that are already maintaing their own packages, so they can see which things change from one release to the next (files added/moved, new configure options, etc). - Third, it will allow distributions to add GNOME. Writing a proper spec file, or creating a good debian/ directory takes quite a bit of time, and can be hard to do if one doesn't have a lot of expierence with it. Having some packages already available will give new distributions a good place to start. - Fourth, a completely "un-branded" GNOME is nice to have. GNOME packaged directly from CVS won't have any Ximian, Red Hat, Eazel, Sun, or other company logos, because those are things those "VAR"s can add to their distribution of GNOME to make it theirs. - Fifth, working packages could enable GNOME to do additional "testing" cycles beyond the release team planned cycles. The Nautilus and Evolution projects have done this already, and it's worked out great. They're able to ensure the CVS versions continue to compile, and it gives them a hugely broad testing base, compared with what they'd have if people needed to compile from CVS. Frequent builds also mean people can test if their bug has been fixed in the latest build, making the bug fixing process much less painful.