Re: RFC: GNOME Packaging Project

[chrisime uni de (Christian Meyer)]

On Sat, Apr 14, 2001 at 10:50:42AM -0700, Gregory Leblanc <gleblanc cu-portland edu> 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.

I agree here.

> - 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).

Very good idea. But isn't it hard to do?! It means much work, IMHO.

> - 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.

Maybe at least slackware users can benefit from it(let's say certainly).

> - 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.

I don't care about logos and other stuff, but I also think it is nice
(means some more work).

> - 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.

Nice too. But we have to ensure that these packages are really
working. 8)

> 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.  

Should we write a webpage for these instructions? Can be useful for
new volunteers. It's very nice to have something on the web rather
than in CVS, etc.

> - 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.

Sounds reasonable...

> - 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.

Beside evo and nauti; how often do you plan to provide new versions? I
think once a day is more than enough.

> 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.

OK. Lemme check, i have a fast machine, 128 MB RAM, debian + the most
important thing: some diskspace left. I know some bits of
dh_make/dpkg-buildpackage but if I want to know more there is a good
documentation available.
The bad: I'll have hardly enough time over the next few month since
university starts in one week.


> 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.

As I said I could help (for debian packages), but I cannot do that
alone. It's not that trivial ;)

Greets,
Christian

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers