Re: GNOME libs 1.0.7 has been released

[Erik Walthinsen <omega cse ogi edu>]

On Sat, 10 Apr 1999, Mark Hankins wrote:

> > Maybe a group of gnome users can volunteer to do this and take the weight
> > of the gnome maintainers?  

Heh.  Believe it or not, I'm building gnome-libs-1.0.8 RPMS right now.  I
have a full chroot'd build environment set up on my machine at work
(PII/350 w/128MB and two fast SCSI disks [soon to be striped]), with
scripts and dependency information and so on all ready to go, just needing
a little TLC and more coding for them to be fully functional.

Basically, if my machine would stay functioning (funky hanging problems
I'm going to have to deal with *RSN*), I should be able to build an entire
set of the core GNOME packages into RPM in well under 24hrs.  I keep a
local mirror up to date fairly frequently, and all the scripts are
currently set up to snag the latest and greatest tarballs from the local
mirror.

Eventually, I'm going to have scripts that will support multiple build
sets, which will allow easy extension into non-core packages while
retaining compatibility with the 'most recent' release.  I.e. someone with
GNOME-1.0 installed might want to try the most recent compatible
gnome-pilot.  One of my 'build sequences' will be gnome-1.0 with the most
recent compatible packages built against it.  Another will be bleeding
edge everything.  Once gtk-1.3.x is running, that'll mean more sequences.

So, I'm close to having an up-to-date bleeding-edge set of RPMS available
for download, as soon as I get them all built (one at a time so far).
I'll put these on my website (see .sig for a subpage of said site), and
people can snag them as they wish.  I would like to find someone to host
the RPMs instead of myself, though, since last time I was involved in
putting something large and popular on the site (the StackGuarded RedHat
5.1 distribution [insert shameless plug for StackGuard talk at the Expo])
it was obvious that our network link isn't top-notch.

At a more developmental level, I just saw someone post a new .spec.in file
for gnome-core, offering to maintain more.  This is good.  In trying to
automate the building of these things, I've found all sorts of tweaks
necessary in a lot of cases because some people just aren't paying enough
attention to the spec files.  For instance, the gtk-1.2.0 spec file listed
libgtk+-1.1.so in the files section.  Um, that's supposed to be
libgtk+-1.2.so...

I'm hoping that getting an automated build process set up (slimmed down
Tinderbox, essentially) will help push people into cleaning up the build
process overall.  What I learned while doing the aforementioned StackGuard
distribution (spent 2 months rebuilding all of RedHat 5.1 with a different
compiler) is that RPM only works when everything is done right.  If your
build environment is funky and not reproducible, don't even bother.  I
asked Erik Troan if they (Red Hat) had a single build environment to build
a new release with, he said "I wish...".

I think I've come up with a decent rule that applies nicely here: the
author and packager should never be the same person.  The author should
hand all the bits to the packager necessary to create a package in a
complete vacuum, else the package will be funky and irreproducible.  For
this, CVS and frequent tarball releases are a boon.

Anyway, I'll try to get a set of recent RPMs up tomorrow on my site and
announce them, then get some kind of cron job going on this thing.

TTYL,
    Omega

         Erik Walthinsen <omega@cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user