Re: Problem with 2.1.57 loading Octave binary format data file

[Glenn Golden]

Przemek Klosowski writes:
>
> Glenn Golden writes
> > 
> >    Of course these are just annoyances and can be worked. My whine
> >    was just that when one is hard pressed for time, doing a source
> >    install of a new gcc version is a far cry from "rpm -Uih
> >    gcc-x.x.x.rpm", which I've become spoiled with. 
> 
> That's why it's nice to use tools which resolve dependencies, like Debian
> package tools or yum in the RPM space. I can't say for sure that it'll work,
> but I think you have a good chance with 'yum upgrade gcc'.
> 

Thanks for the suggestion, but I'm pretty sure that 'yum' or any other
RPM dependency resolution tool wouldn't help in the present situation,
because the problem isn't dependency resolution of RPMs, but the fact that
that there does not exist a newer gcc RPM for the RH release that I'm
running (7.3).  I'm already using the latest vendor-built gcc RPM that is
available in RedHat's 7.3 "update" tree, and it's considerably older than
the version that David is suggesting.  Afaik, there's not even a more
recent (RH) SRPM for 7.3.  Hence the tarball build.

But your suggestion is well taken.  I might try 'yum' at a later time,
although  -- and perhaps I shouldn't admit this :) -- I find that "manual"
dependency resolution (when the desired binary RPMs dependents are
available!) isn't usually that time consuming, at least for tools with
only a small handful of dependencies.  It's old-fashioned, but it's
usually not quite time-consuming enough to cross my annoyance threshold
and do something about it.  With a small amount of manual intervention
(rpm --test, see what dependencies are missing, download, repeat...) it's 
usually just a few minutes effort, at least if you've got a fast link and
a responsive mirror site.  The only "work" involved is downloading RPMs,
and then once you've got the critical mass, just 'rpm -U' and it's done.

OTOH, resolving dependencies when doing source builds -- as in the
present case -- can be a lot more time consuming because you're on your
own as far as identifying the dependencies, and then you frequently wind
up having to source-build the dependents themselves, and then those have
dependencies... .  That's the form of time-consuming dependency-hell I
was whining about, because iterating down _that_ tree can often involve
more than just "./configure; make; make install", and with a nontrivial
probability of non-success on the first shot. :)


>
> THe problem with yum is that it's commandline,
>

Ahem. :)  


> and the default Fedora config hits just the RedHat servers, which are
> bandwidth limited to something like 15kB/s.
>

Try the Compaq RH mirror. I frequently see 400kbps+ and it has amazingly
good availability.  I don't know where it (or you) are located but it
really rips from where I am (Colorado, US.)


Glenn



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------