Help for the guru-less

Josh Sled jsled at asynchronous.org
Thu Feb 22 15:49:50 EST 2007


On Thu, 2007-02-22 at 11:10 -0900, Lewis Overton wrote:
> What I would LIKE to see is a list of dependencies that break version
> whatever of the main program or, alternatively, those that seem OK. Seems
> like a lot of work to extract that from somewhat loose reports of troubles,
> especially when there are so many *nix distributions to consider. Wishful
> thinking.

Yeah, it can be frustrating, but it's a bigger, general problem ... and
of software, not just unix distros.  I mean, microsoft knows this
problem very well ... and even bringing all their resources to bear on
their own controlled software platform, they still have released targted
bug-fixes that cause problems.


At the macro level, the software does configure against specific
versions that are known to work ... specifically that are known to have
the API/ABI that the software is written to use.  At the minor/micro
level, it's in large part up to the cloud of users to feedback things.
As you say, there's some good wishful thinking in there about
correlating that core information across communication fora...


> I suppose the way to test a new release is to download all the dependencies
> and libraries into a completely separate test environment and try it out as
> far from "reality" as possible. I wonder if that can be done safely on a
> single machine.

This is generally the function of the stable vs. unstable "lines" within
most distributions ... unstable updates more quickly, but has the
potential to break, and users self-select (and are expected) to be part
of the quality assurance process.  Stable moves more slowly, but should
be well-tested.

"Jail" environments and virtual machines are both good ways to make that
process simpler.


> Seems like the core of the issue is 'if it ain't broke, don't break it.'
[...]
> them. That includes the world-famous geophysicist next door, who only
> recently got rid of Windows 95.

I'm of two minds about it.  "If it ain't broke [...]" is a time-tested
maxim, to be respected.  But it sure seems like the only successful
pattern for dealing with complex general-purpose software systems has
been one of regular, measured, incremental updates.  Of course, their
complexity implies that they're always "broken", and thus always need to
be fixed, so it's a bit self-fulfilling.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20070222/e1c017d8/attachment.bin 


More information about the gnucash-user mailing list