Suse 6.4 then Helix (Was Re: question) - and a few issues

["David T. Bath" <bathd edipost auspost com au>]

Wandered Inn wrote:
> 
> Giovanni Tommaseo wrote:
> >
> > Hello,
> > I want to update some rpm files of gnome 1.2 over the YaST (I have SuSE
> > 6.4 on my machine).
> > Could I have some porblems after the update?

1. If you get GENERIC helix RPMS, then you are in for trouble.
2. Make sure you get the RPMS for SuSE 6.4 (not just SuSE)
   Helixcode have obviously gone to a fair bit of work to
   make this stuff distro-specific.  We'll see how good they
   are when SuSE 7.0 is out in a couple of weeks.
3. The install worked fine apart from two missing libraries when
   gmc tried to start:
   a) /usr/lib/libext2fs.so.2
   b) /usr/lib/libcom_err.so.2
4. Solution
   mkdir /somewhere
   cd /somewhere
   cp /usr/lib/libext2fs.a .
   ar -x *.a
   gcc -shared -o /usr/lib/libext2fs.so.2 *.o
   rm *
   (repeat same process for libcomm_err.a)
5. No problems.

and tangentially..........

There is an issue here about package names
a) I want consistent names, so I can update straight from
   the "official" GNU source (e.g. gnome-devel-x.xx.src.rpm)
b) I can see SuSE's point in keeping names short for easy
   loads and searching CD's for people unpacking on systems
   (a la windows) that cannot handle long CD names (e.g.
   neither Joliot or RockRidge extensions).

Another possibility is that the RPM databases permit
"aliases".  This might be tricky given the db structure
used.  Ideally the alias database would allow entries
to be hacked.

Similarly, there is an issue on WHERE the darn stuff is
installed.
a)  /opt/gnome is nice, fits in with /opt/kde.  Separates
    stuff nicely ..... BUT
b)  installing in default /usr/local/ makes config easier.
c)  installing in /usr makes default lib searching easier.

I think it is time to let the various distributions sit
down and nut this out, like they did the FHS.  Maybe
the Gnome Foundation could act as arbitrator.

Similarly, while there are many optional libraries that
might be in, but can be out, it would be great if
the Gnome Foundation (or staffers from IBM/HP/Sun/Compaq
and the distributors) maintained a dependency map
the could be quickly pulled from the net, so that
package downloads and compiles could be properly
planned.

Admittedly, this requires package developers to be
disciplined.  For example.  I go to pull down evolution,
and the site (thankfully) says "pick up glibwww2xxx here".
Try and install or compile that and there are multiple
complaints about libwww!  If these sorts of issues are
allowed by vendors to get out of hand, then sadly, Gnome
will fail in the non-hobbyist arena.

Maybe the Gnome Foundation should put their foot down and
stamp disciplined, portable (not just Intel Linux) apps
as "Gnome Components" with a seal of approval, versus
software that "uses Gnome".

It is in the commercial interests of the distributors
and hardware vendors to get this right.  If the Gnome2
distribution is to be the "saviour", then they should
start putting these disciplines in place NOW.  It's
going to be tough enough looking after compatability
issues between extant apps and the new libraries.

Its in the commercial arena, on multiuser machines,
the big non-Intel boxes that the Gnome can unify
Unix, Be, MacX, and a resurgent DecWindows, making
it easier for the hardware vendors to compete.

The public codecutters can do the job of programming,
with assistance of tools offered by vendors.  But they
have always been good at that.  GNU/FSF/Linux/BSD would
not be what they are without that ability.  But the
commercial members of the Gnome foundation have the
infrastructure to do what they are good at, especially
documentation and quality testing.

Sorry for the bitching, but I think things might be
getting out of hand here, just when the winning post
is in sight.
-- 
David T. Bath bathd@edipost.auspost.com.au
+613 9204 8713 (W) 0418 316 634 (Mbl)