Re: more gnome 2 proposal

[Havoc Pennington <hp redhat com>]

Alex Graveley <alex ximian com> writes: 
> My personal view is that this is a major mistake. You run the risk of
> continuing the tradition of difficult builds and complex
> dependencies.

Nah - if all you want is one big tarball, it's trivial to make a
toplevel Makefile that builds all the subtarballs using
AC_CONFIG_SUBDIRS(). That's a quick weekend hack.

Also, I would point out:
 - most people use packages
 - we already have so many dependencies to build say Nautilus that 
   this gnome-libs breakup is barely a drop in the bucket

The reason builds are historically difficult is that stuff does not
build and APIs keep changing. Tinderbox, branches, and decent release
practice chills that out a good bit. We are also not chasing a moving
GTK this time, hopefully.

> Keeping everything in one or two modules is nearly guaranteed to fix
> both problems.

And introduce a host of more serious ones. We can do a virtual module
that sucks in a bunch of submodules and has a toplevel makefile, in
fact a script to do that is a requirement for Tinderbox.
 
> What this does mean is that development for Gnome becomes a hard
> target for third-parties. You would be able to develop against the
> currently released frozen Gnome API, not whichever API is current
> for a module, or whichever version of packages a given distibution
> decides to ship.

All the libs freeze at once and remain so, they are not allowed to
vary independently. That's how it works even today for libs that have
been released for 3rd party use.

Empirically, gnome-libs has been a huge disaster, while lots of small
separately-maintained modules such as ORBit and libxml and gnome-vfs
and gdk-pixbuf have done relatively well. In my view the problem with
gnome-libs is that it has no clear statement of purpose or function,
and no person doing full-time or sufficient-time work on it. It's just
a place where random people have dumped random stuff. One way to fix
the mess is to create individual modules with clear purpose, clear
function, and clear babysitters.

I would also point out the "Imlib problem" or "GtkXmHTML problem"
which is that tightly integrating everything has nasty consequences if
you decide one of the things was broken and should be replaced.

Of course I can also refer you to my previous Dependency
Manifestos. ;-)

We can use pkg-config and its dependency/conflicts mechanisms to
enforce a single platform; for example it can have a "gnome-2.0"
module including all the libs, or it can have conflicts with versions
greater than or less than a given number. App developers really don't
have to know about how many shared libs or packages are involved here,
and they can get nice warnings if they mix-and-match versions
inappropriately.

Finally I'll whine about build time for a single package - fixing a
bug in gnome-libs is an enormous PITA, because rebuilding that bastard
takes ages already. Add a few new big libs in there...

Havoc

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