Hi Russell,
On 13/03/2008, Russell Gadd <russ.mail.lists@???> wrote:
> I previously (fairly recently) asked for advice on which distro to use
> between Debian Etch, Debian Lenny, Ubuntu, Fedora. After reading all the
> contributions I plumped for Ubuntu. However I came up with a problem in
> OpenOffice. In a Calc spreadsheet file it would not print any sheets other
> than the first. I filed a bug report and got an answer that this was fixed
> in the upcoming Hardy so it was going to be ignored for Gutsy.
I think I found your bug [1]. It's unfortunate that we don't know if
there's a definite bug fix or the respondent simply tried it in Hardy.
If you still have Gutsy installed I would suggest enabling the
recommended updates in case it is fixed there.
[snip]
> I really much prefer to wait and run stuff after it has been properly tested
> and debugged, so Debian Stable really appeals to me as a system more than
> Ubuntu.
[snip]
> The real point of all this is to ask about bug fixing as regards Debian
> Etch. Taking Gnucash as an example, when I look at the progress of updates
> on Gnucash's web site, I see that each update fixed bugs in previous
> versions (naturally). However suppose I am running an older version in Etch
> and a bug comes to light. This may well have been fixed in a later version,
> but I am assuming that Etch won't have adopted that version. I presume the
> Debian philosophy is that fixing most software is not a Debian issue
> (exceptions maybe are security problems). So what are my choices?
You'd like thoroughly tested and debugged software, but you'd like the
bugfixes to be shipped very quickly. If such software exists, it is
probably very expensive.
The crux of the problem is this: new versions of software include bugs
of unknown severity, even if they also fix existing problems. Debian's
response to this problem is to avoid adding risk to the stable
version, by simply only fixing things of high severity. This is
probably a sensible strategy when your QA consists of whatever the
package maintainer can do and bug reports from those of your users
that live on the bleeding edge.
> Obviously I could run multiple OS's and use one which supports the later
> version for just this one application - perhaps using Virtualbox or similar
> (at present I multiboot a few OS's, but switching between them involves a
> round of rebooting, and is much less convenient e.g. re cut and paste across
> apps).
>
> Another might be a backport. There isn't a backport of Gnucash for Etch, so
> this is not available as a binary package.
>
> Could I get the source and recompile it for Etch? I have never attempted
> compilation, so I don't know what is involved. I suspect there is a
> significant learning curve. I fear that I may break something in the
> packaging system. Is this what other people do? How difficult is it to
> maintain such a tweaked system when new components, point releases or
> system upgrades are released?
I compile software myself when I need a particular version and try
using the distribution-supplied package when it catches up. I don't
like having to update many bits of software myself, so I don't
generally bother unless it is important to me. I don't remember
compiling things myself ever causing me an issue during upgrades.
If Gnucash is well put together and well documented, then it shouldn't
be too hard. You need to be prepared to read the documentation (the
convention is to start with the README) and possibly install a few
packages that are needed to build it. Whether you want to spend the
time is up to you :)
> Well these are my thoughts. Please feel free to rubbish them (preferably
> adding some other ideas).
Regards,
Graham
[1]
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/200514
