Troy J Dawson wrote:
> Vladimir Titov wrote:
>>>>>>>  On Wed, 5 May 2010, Oleg Sadov wrote:
>>>>>>>
>>>>>>>>  Date: Mon, 03 May 2010 10:18:06 -0500
>>>>>>>>  From: Troy Dawson <[log in to unmask]>
>>>>>>>>  To: "[log in to unmask]" <[log in to unmask]>
>>>>>>>>  Subject: gnuplot42 in SL 5.5
>>>>>>>>
>>>>>>>>  Hi All,
>>>>>>>>  I haven't seen any conflicts yet.  How do people feel about putting
>>>>>>>>  gnuplot42 in SL 5.5?
>>>>>>>>  I give it a thumbs up, but I wanted to know how others feel before
>>>>>>>>  putting it in.
>>>>>>>>
>> There are some small differences between 4.0 and 4.2 version,
>> but I don't see why we should use old version.
>>
>> However, now the newest version exists, gnuplot-4.4 (see
>> ftp://ftp.linux-ink.ru/pub/SLCE/5rolling/testing/{SRPMS,i386}/gnuplot/*.rpm).
>> Some bugs are fixed, some terminals are added,
>> some new features are released. Why we have to wait a while
>> before using this version? A few useful applications
>> use gnuplot as graphical tool, for example octave, maxima etc.
>> Gnuplot tends to fit these applications (wxwidget etc.)
>> and we must use newest gnuplot version.
>>
>> Vladimir Titov, Linux-ink
> 
> Hi Vladimir,
> If a package is supported by RedHat, we are not going to change it just 
> because it is old.  If we were to do that then we might as well update 
> the entire release each time.  That is not what Scientific Linux is about.
> Scientific Linux is an Enterprise linux, which means that packages 
> remain stable.  Sometimes those packages get old, but they remain stable.
> The package gnuplot42 is not updating the gnuplot that RedHat already 
> supports, but add's another package.  It is packaged so that a person 
> can have either the old gnuplot, or the newer 4.2 gnuplot installed at 
> the same time.
> But, you do have a point.
> If we are making this new gnuplot42, why make it 42 instead of 44.  The 
> easy answer is that when this was started, 44 wasn't released.
> 
> What do people think?
> Should we change gnuplot42 to gnuplot44?
> That shouldn't be too hard.
> Is there any technical reasons why we wouldn't want gnuplot44?
> 
> Troy
> p.s. SL 5.5 Release Candidate 1 will have gnuplot42, but if we work fast 
> on this we could have gnuplot44 in the final release.

Things got very quiet about this.
I've been having a hard time getting gnuplot44 to build, it seems to 
want a newer autoconf or something, but right now I really don't have 
the time to mess with it.
Since this is a last minute change, I would feel better with staying 
with gnuplot42 for the release of SL 5.5.  That's what's been in testing 
and everyone who tested it said it worked for them.
If someone wants to take the source rpm from gnuplot42 and figure out 
why it's not compiling, why don't we see about getting that into SL 5.6.

Thanks
Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__________________________________________________