Re: [Hampshire] Unsupported Etch updates

Graham Bleach wrote:
> Hi Russell,
>
> On 13/03/2008, Russell Gadd <russ.mail.lists@???> wrote:
>
> [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.
>
>
Yes I like thoroughly tested and debugged software which is why I like
Etch. I didn't say I expected the bugfixes to be shipped very quickly, I
realise this is quite unrealistic. I'm just exploring what to do when I
have a problem which may have been solved in a later version.
> 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.
>
>
Yes I realise that if I introduce a later version I may get new bugs
coming to light. I'm not sure if this is more likely as these versions
haven't been out so long. One of the replies to my post said that Debian
maintainers do lots of bug fixes but they won't likely go into Etch
unless they involve security. When you say "by simply only fixing things
of high severity" I suppose this means something judged severe even if
not a security issue. Anyway the policy seems good to me.
>> 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 :)
>
>
This is the sort of comment I was after. Thanks for your response,
Graham, I appreciate it.

Russell