SCIENTIFIC-LINUX-DEVEL Archives

January 2012

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael Tiernan <[log in to unmask]>
Reply To:
Date:
Wed, 25 Jan 2012 16:19:38 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
On 1/24/12 4:26 PM, Connie Sieh wrote:
> Why can you not fix it until the "next distribution" comes out?

I'm not answering for Mr House, this is only my opinion.

For some free-standing applications, sure, you can just go and run a 
configure/build/test/install and you're happy.

For some of the more tendril bound applications (i.e. based on KDE, 
Gnome, etc.) this task becomes much more difficult quickly. Not the 
least of which is, I don't think there's a way to find out that 
application "X" was built using a specific string of options passed to 
it (or what those options might be) in order to build a duplicate of the 
existing application. (If I'm wrong, *PLEASE* tell me.)

After you've eliminated the usual pilot error, the next step will be to, 
usually, replace the application on the user's system with the same 
application with debugging turned on, identify the problem, rectify it, 
and then install the fixed application on all the user's systems and, 
hopefully, provide the patch upstream for others.

Without knowing exactly how (and in a deterministically reproducible 
manner) a package/rpm/application was built, then tracking down a 
problem is going to be nothing but layering on of problems.

ATOM RSS1 RSS2