11/05/2010 18:38 +0200, Matthias Schroeder wrote:
> Hi Troy,
> 
> Troy Dawson wrote:
> > 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?
> 
> Waiting a while gives the very fresh 4.4.0 some time to mature, and to 
> have a few bugs fixed. 4.4.0 has been released in March, so waiting a 
> little seems to be a good idea.
> 
> >>> 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.
> 
> In that case it should be checked that the provided gnuplot is working 
> with the versions of these apps that are in SL, right?

Of course -- this is a right way.

By the way -- colleagues, what do you think about necessity such kind of
software for SL users? We prepared a lot of scientific software for
SL-compatible distributions in our repositories:

ftp://ftp.linux-ink.ru/pub/SLCE/5x/yum/slce.repo
ftp://ftp.linux-ink.ru/pub/SLCE/5x/yum/naulinux.repo

Would it be helpful for scientific society? Which another software
packages may be interested?

> >>> 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.
> 
> Replacing the version after the rc phase doesn't sound good...

Exactly.

> > 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.

Strange... Ok, Troy, we will check package rebuilding process again.

> > Since this is a last minute change, I would feel better with staying 
> > with gnuplot42 for the release of SL 5.5. 
> 
> Agreed.

+1

> > 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.
> 
> That sounds much better.

Sure.

> Matthias
> 
> > 
> > Thanks
> > Troy

--Oleg