Re: RFC: GNOME Packaging Project

[Dan Mueth <dan eazel com>]

I think this is an excellent idea.  It is essential that we have binary
packages, both for our official beta releases/release candidates as well
as for snapshots from CVS.  They are needed by people who do formal QA,
write documentation, do translations, etc., as well as for the potentially
numerous informal testers from the community who are largely unable to
do testing and provide feedback without this project.

The project will also serve as a hub for various packagers and developers
to discuss packaging issues.  This will help distributions to adopt GNOME
and make the GNOME they ship work better.  It will also help developers of
GNOME-related software (eg. the packages in the GNOME Software Map)
package their software, providing users with a larger body of properly
packaged GNOME applications.

Dan

On 14 Apr 2001, Gregory Leblanc wrote:

> Hi folks!  GNOME 1.4 is out, and we should all be back and at least
> partly recoverd from GUADEC, so it's time to do some more GNOME stuff.
> This message is a proposal for a GNOME packaging project.  I'm looking
> for comments on the idea of the project itself, and on the
> implementation as I've proposed it.  
> Let's start with why we need a "GNOME Packaging Project".  
> - 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.
> 
> Now that I've covered why this project is needed, it's time to cover
> some details on the project itself.
> Scope: The GNOME Packaging Project (GPP) will have three primary goals.
> They are listed here from most important on down, but please don't take
> that to mean that the last goal isn't something important.
> - First, the GPP should provide automated packaging instructions (ok, so
> I made that term up, but it means things like spec files, and dpkg
> debian directories) for the major packaging systems.  To start with,
> this should include RPM spec files, and dpkg debian directories, as
> these are the most widely used package formats.  Hopefully we'll get
> volunteers to package things for some of the other breeds of *nix out
> there, so that we don't seem so Linux centric.
> We need to get these into the modules in GNOME CVS, and we need to make
> them well integrationed with the package.  By well integrated I mean
> that when the program author changes the version of gnome-libs that's
> required, this is automatically reflected in the automated packaging
> instructions, and other things along these lines.  
> - Second, the GPP should provide binary packages for both stable and
> unstable releases of GNOME packages.  This means that when a new version
> of a gnome package is released, we grab it, and compile it on whatever
> machines we have available.  It also means building packages for major
> release cycle betas, such as the GNOME 1.4 beta/release candidate
> releases.  Having these binaries available is -critically- important in
> order to do any reasonable level of testing.
> - Third, the GPP should look to provide regular and frequent builds of
> GNOME from CVS.  These should be akin to the hourlies and nightlies that
> Nautilus and Evolution provide, respectively.  This becomes rather easy
> if we have good dependancy tracking, and good automated packaging
> instructions, although it's still intensive on computing resources.
> 
> Now it's time to get down to what resources we're going to need in order
> to get this done.  We'll need volunteers who know a bit about RPM, dpkg,
> and other software packaging systems in order to get the automated
> packaging instructions whipped into shape.  This has already been worked
> on quite a bit, but needs to get finished/polished, and then put back in
> CVS in the appropriate modules, and integrated with those modules.  
> We'll also need to have somewhere to build binaries for a few different
> platforms.  This means a fast machine, with plenty of ram and drive
> space.  Ideally an SMP machine with SCSI drives and a good controller,
> so that it doesn't get bogged down by lots of disk use.  There are some
> other technical issues, but nothing that we can't overcome.
> 
> Now you know what we need, why we need it, and what resources it'll take
> to get this done.  I'm looking for thoughts on what I may have missed in
> writing this, and for some feedback on the idea itself (since I'm going
> to get that anyway).  Finally, I'd like some support from the people
> maintaining the GNOME modules in CVS in the form of timely review of
> patches, so that we can get the first part of this project done as
> quickly as possible.  Thanks,
> 
>     Greg
> 
> 
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 
>