"Hello, World" report crashes Gnucash

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> Well, my headache and a headache for all the Gnucash users who are
> still using RH 6.2 (and I bet there are a lot of them!).  If Gnucash
> only works on the latest-and-greatest then we've got a major
> problem.  I don't want to thumb my nose at users of last year's
> technology.  Sure, people running RH 4.x (or maybe even 5.x) are
> outdated enough that we can yell at them, but RH 6.2 isn't all that
> outdated (yet).  Indeed, RH is currently only at 7.0 release and is
> beta-testing 7.1.

I think maybe there's some confusion here.  When a "real release" gets
closer, there will always be the process of figuring out which systems
we need to support, and how we have to support them.

In this case, taking the gtkhtml issue as an example, it's my
understanding, that it is *impossible* (or nearly so) for us to
support the gtkhtml that comes on a *stock* RH6.2 system.  That
doesn't mean that we have to (or necessarily would) force all 6.2
users to upgrade their entire system to something else.  It means that
we'll have to step back and ask the question you always have to ask on
the development side: What should we do?  How to the costs of the
possible solutions in terms of development time compare to the
benefits and burdens those solutions will provide/impose on us and on
the users.

In this case, off the top of my head, possibilities would include

  1) Require users to upgrade their entire system to RH X.X.

  2) Require users to upgrade some subset of their packages, using
     packages either from RedHat or perhaps from us.

  3) Provide a set of 6.2 "helper" packages that install gtkhtml (and
     dependencies) in a "sandbox" directory, and set up the gnucash
     6.2 rpm to use those, via LD_LIBRARY_PATH or -rpath.

  4) Require users to build/install gtkhtml and friends to
     /usr/local/foo according to a 6.2 recipie we provide.

  5) Provide a GIANT 6.2 RPM with everything needed statically linked.

  ... etc. etc. etc.

My point is that all of these possibilities involve tradeoffs, and
figuring out which battles are worth fighting and how hard is an
important and painful part of the development/release process.

Suffice it to say that we *will* address these issues at release time,
but until a stable release is near, the longer we can delay, the
better, because as time passes, the set of issues we'd need to address
constantly changes.

WRT RH 6.2, for now I think you can rest easy.  AFAIK, Dave has made
it clear he plans for us to support 6.2, much to my guile and g-wrap
related dismay :>

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930