> The 'Gnome' way is (besides hard to maintain and packageize) a
> b*tch to upgrade for end users. For KDE, the update involves pretty
> much just kde* packages, only kdelibs+kdebase are really necessary
> for many of end-users and it's reasonably easy to figure the
> dependency tree when you only want to update the KDE desktop items.
> 
> For Gnome, it's dozens of different packages all over the place, whose
> name doesn't even suggest it's part of Gnome. Are you going to use
> libbonobo{,ui} without libgnome{,ui}, libgsf without gnome-vfs2,
> gail without atk etc? gnome-base lists 59 (!) different dependencies,
> and those pull in countless others as subdependencies.

But is not this a problem with updating procedures rather than with
the packages? If a user were able to say 'upgrade gnome' (by telling
the tool to upgrade the dependency tree starting with the gnome meta
package at the top), the amount of packages would not be a problem.  I
hope to implement cherry picked upgrading in pkgmanager in the future,
to allow for precisely this.

I'm not a gnome user, but if this were to be KDE I would probably
prefer smaller packages. For example, the other day I wanted to
install kmail. If I can install kmail by compiling 50% of KDE instead
of 100%, that is a significant saving in compile time (especially when
you factor in future upgrades). In my case I couldn't be botherd to
figure out which kde package contained kmail, so I just installed all
of it :)

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org