[NTLUG:Discuss] GNOME and GNUCash install difficulties

[Christopher Browne]

On Thu, 01 Jun 2000 00:14:57 CDT, the world broke into rejoicing as
Kevin Brannen <kbrannen at gte.net>  said:
> Christopher Browne wrote:
> > 
> ...
> > That still may leave some inconvenience in trying to retrofit to
> > SuSE 6.1.  This maybe SuSE's sign that you need to upgrade to
> > "6.newer."
> > 
> > [Does it irritate anyone else that so many Linux systems are
> > nearly as slavishly dependent on regular version upgrades as is true
> > for the moves between non-interoperable versions of MS Office?  Off
> > the soapbox...]
> > --
> 
> <soapbox>
> 
> Yes!  Loading from a CD distro and getting it customized & stable is
> pretty easy now-a-days, IMHO.  But trying to upgrade (or sometimes
> add) 1 package that has lots of lib dependencies can be a real killer.
> 
> IMNSHO, I think a lot of the blame goes to the GNU folks who foisted 2
> incompatible versions of glibc on us in a very quick timeframe (or it
> seemed quick to me. :-)  That had a tremendous cascading effect on the
> other libs, which cascaded to many apps.

That's arguably blamable on the RHAT folks, that leaped to adopt
GLIBC 2.0, when that was, most definitely, "beta" code.

Mind you, there _was_ a desparate need, at the time, to have _some_
sort of LIBC to support non-IA-32 architectures, as LIBC5 was only
ever stable on IA-32.

Can I argue for a third place to foist blame?  How about, "on a community
that succeeded in not bothering to put together much in the way of
automated test cases."  The folks that _do_ have test material prepared
are those at Cygnus; the "just about everyone else" that was racing to adopt
GLIBC 2.0 didn't seem to have _any_.

> On a related note, I tried to take /usr/i486-linux-libc5/lib out of my
> LD_LIBRARY_PATH earlier this evening and had some very rude suprises
> (I tried that because gnome was finding the wrong libs and failing). 
> If I had to name the top 2 Open Source Software problems, #1 would be
> lack of business apps (slowing getting better), and #2 would be the
> inability to move forward "as a whole" when change is needed.  (M$
> seems to do better here, but then you're also stuck with the problem
> of separating the OS from the Apps. :-)
> 
> Examples of #2 comes everytime I have to upgrade, then finding
> programs which ran just fine before, now suddenly failing.  Why? 
> Because the app uses /usr/bin/wish4.0 while the new distro only
> provides /usr/bin/wish8.0 (and just uninstalled wish4.0--ARGH!!!). 
> Will the app work with wish8.0?  How should I know!?   And there is no
> new version of the app out.  (Fortunately they all have worked so
> far.)  Other examples could be provided if I thought about it enough.

What this particularly manifests is that Having Source Is Important.

One thing that the BSD folk have _right_ is that they can do a 
"make world" and (pretty much) see everything recompile, thereby
cleansing out any such annoying incompatibilities.

Obviously this doesn't help you much if you're installing
WordPerfect from the "precompiled tarball."  But it _does_ work
out well for packages for which you can get code.

> I really like SuSE.  I think they strike a good balance between OSS
> and comercial software; but I do hate it when they do this to me.  To
> be fair, I don't think this is just a SuSE problem; I hear of similiar
> problems with RH (and others) too.
> 
> And before someone tries to tell me that RPMs are the answer, please
> point me to a good RPM tool (w/ GUI please) that not only supports
> binary RPMs, but source ones too.  I've yet to find one that does
> source.  I'm not sure what RPM *should* stand for (i.e. I haven't come
> up with good replacement words for the acronym), but I find them hard
> to use.  If it wasn't for rpm2cpio, I wouldn't have installed some
> packages I really need and use on a daily basis.
> 
> And all that adds up to making it hard to upgrade distros manually,
> forcing me to use the distro upgrade more frequently than I probably
> should have to.  [I'd love to skip SuSE v6.5, but the thought of
> having kernel v2.4 is so alluring. :-]

Of course, nothing prevents you from installing kernel 2.4 on whatever
system you've got; it will probably work fine with just about
anything newer than an a.out-based distribution.

Some people seem to get Very Concerned about how Debian is just
Dramatically Out Of Date due to not including the Latest Kernel Release;
that just _bewilders_ me when it's relatively straightforward to toss
in a new kernel.  I used to, as a matter of course, install the latest
"bleeding edge" kernel on a weekly basis, not necessarily actually ever
_using_ some of them, as I didn't necessarily reboot during that week.
That was with Red Hat; I _never_ encountered _any_ troubles in putting
in my own kernel.

The only _severe_ problems I've ever had have been in having upgraded
an Alpha box to "Debian Unstable," and finding that it very badly needed
a 2.2 kernel (2.0 would Not Do) in order for the clock not to go bonkers.

Long and short is, if you think 2.4 is alluring, then install it, already.
You won't put your PC "out of warranty" by doing so...
--
cbbrowne at acm.org - <http://www.ntlug.org/~cbbrowne/linux.html>
Giving up  on assembly language was  the apple in our  Garden of Eden:
Languages  whose use squanders  machine cycles  are sinful.   The LISP
machine now permits LISP programmers to abandon bra and fig-leaf.
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982