Re: shared-libs & installation (was gnome-socket API proposal)

[Andres Rodriguez <andresrc arrakis es>]

Hi!

First of all, hi everyone, as this is my first message in this list
(I've reading it for a while).

Derek Simkowiak wrote:

> 
> > Good point, performance won't hurt due to a larger lib. But there are
> > major logistical problems; larger libraries are much harder to maintain
> > and make releases for [...]
>         I agree with Havoc on this one.  He makes some strong points about
> maintainability.
>         I just don't want to revert to the Gnome 1.0-style installation
> nightmare [...] 

I think thre are two maintainability problems right there, one from the
users point of view
(final user who are the goal of this desktop project, I think) and other
from the developers' side.

Let's start with the developers. I agree with Havoc on the need of
reasonably sized modules so that people can take care of them quite
easily, releases can be done quite often, and there's a more "dynamic"
development.

>From the users' point of view, maintainability means less packages (less
things to upgrade), less dependencies (since this leads to less
problems), and so on. I know about the "release often" way of doing
things and share it, but I think the typical end user (or the user this
kind of projects try to attract) prefer something between one release a
week and one release in 18-24 months (as in comercial systems) if it
means a greater degree of ease of use. I still remember my
first installation of GNOME being a Linux newcomer (as I'm still are :)
), and only seeing the amount of different packages needed to make a
completely workable system was a bit frustrating.

And so, I think Miguel's idea of a big lib is a good deal to approach
GNOME to end users. The problem is if there's a way to link this
super-lib (or superpackage by the way) from the small pieces so they are
still easily manageable.
If that possibility exists, IMHO, the developers could stand building
their desktop from the small pieces, and after a prudential time (e.g.
every 4-8 weeks) get the lastest stable and tested version of each
little package, build the big one, and send it in a
"here's-your-desktop-up'n'running" way to the public.

In fact, most new Linux end-users (those with little experience) don't
continously upgrade to the lastest kernel, compiler, and so on, unless a
critical reason forces them to. Instead, they just wait for the next
upgrade of their favorite distribution to upgrade as painlessly as
possible, so waiting 4-8 weeks for a no-hassle upgrade it's like no
waiting for them.

To sum up, IMHO, I think we should come up with some model that could
fit the two groups described above.
Sorry for the long message ;-).

-- 
Andres

E-Mail: andresrc@arrakis.es andresrc@esi.us.es
WWW: http://www.arrakis.es/~andresrc