additional packages

[Ben Abbott]

On Feb 29, 2008, at 4:29 PM, Thomas Treichl wrote:

> Ben Abbott schrieb:
>> On Friday, February 29, 2008, at 03:52PM, "Thomas Treichl" <Thomas.Treichl at gmx.net 
>> > wrote:
>>> Ben Abbott schrieb:
>>>>> Hhmmm... Ben, what exactly do you mean by "messy conflict can  
>>>>> arise" - this sounds to me like you can't use Fink packages  
>>>>> anymore if Octave.app is installed?
>>>>>
>>>>> Fink doesn't know anything about Octave.app even if it is  
>>>>> installed and therefore Fink can't use any of Octave.app's  
>>>>> libraries. Octave.app doesn't use Fink's libraries but uses it's  
>>>>> own (Octave.app brings all the necessary libraries needed to run  
>>>>> on its own and doesn't install anything anywhere else on a  
>>>>> user's harddisc). Fink shouldn't modify files that hard on a  
>>>>> harddisc either, isn't it?
>>>>>
>>>>> So where do that messy conflicts arise? My knowledge is that  
>>>>> people using Fink-Octave and Octave.app both on one and the same  
>>>>> machine can use both without conflicting or damaging each other  
>>>>> (maybe they can't use Octave.app and Octave-Fink at the same  
>>>>> time)...
>>>>>
>>>>> This actually is a feature of a standalone application *.app  
>>>>> from my point of view that doesn't work if somebody mixes  
>>>>> distribution installations?!
>>>>>
>>>>>  Thomas
>>>>>
>>>> I'll qualify my prior comment with "I haven't actually tried  
>>>> installing Octave via Fink and via a standalone version at the  
>>>> same time".
>>>>
>>>> Based upon what I've read from others, my understanding is that  
>>>> conflicts can arise if different versions of octave, different  
>>>> version of gnuplot, and/or different versions of aquaterm are  
>>>> installed at the same time.
>>> ... that are all found somewhere on your common system paths (at  
>>> least bin path and lib path), right. Octave.app isolates from  
>>> system paths - that's why Fink doesn't see anything from  
>>> Octave.app - and Octave.app uses it's own system paths - that's  
>>> why Fink doesn't conflict Octave.app.
>> Do you mean to imply that Octave.app includes installations of  
>> gnuplot and aquaterm and that these are isolated from Fink, and  
>> that if these are installed via Fink (and are version that are  
>> incompatible with Octave.app) that there is no problem?
>
> Correct. If Octave.app finds Gnuplot.app in /Applications then  
> always Gnuplot.app is used - you can install so many gnuplots as you  
> want somewhere else on your Mac, they are all ignored. Further,  
> Gnuplot.app includes an installation of AquaTerm and (should - and  
> I'm only 99.9% sure here because of this AquaTerm.framework thing)  
> always uses that AquaTerm and no other one. And like I wrote to  
> Carlo in the other mail, I expect starting two versions of  
> AquaTerm.app at the same time won't work...
>
> A problem may appear if (and it currently seems to me that AquaTerm- 
> Macports makes some settings like this) a system variable or  
> something like this is defined on somebodys Mac, eg.  
> GNUTERM=UnsupportedBackendOrSo (like we had somewhere else on the  
> lists) then also Gnuplot.app doesn't know how to handle this and  
> fails...
>
>> I don't know the answer to that, but have assumed that would be a  
>> potential problem.
>
> Well no, it should not be a problem like I wrote between Octave.app  
> and Octave-Fink, *but* yes it definitely may become a big problem if  
> you install Octave-MacPorts beside Octave-Fink (same libs in  
> different system paths: /sw/lib (for Fink, correct?) and /usr/local/ 
> lib (for MacPorts correct?) )...
>
>>>> The different versions of octave shouldn't be a problem unless  
>>>> ~/.octaverc includes path information.
>>> ... right, then we really would have a problem (like we had in the  
>>> discussion with the savepath command that overwrites .octaverc).  
>>> But even packages can be handled correctly if we have Octave-Fink  
>>> and Octave.app installed, this time if we use the -global option  
>>> for pkg.m, then Octave-Fink packages should go somewhere into / 
>>> sw/... and Octave.app packages should go into /Applications/ 
>>> Octave.app/...
>>>
>> The global option will work fine provided the versions of Octave  
>> are compatible with the packages, correct?
>
> Correct.
>
>> Personally, I'd like to be able to run different versions of Octave  
>> at will. Can I do that by installing Octave bundles?
>
> What do you mean by installing Octave bundles?

I'm mean different Octave.app's. Say 2.1.9, 2.9.15, 3.0.0, ... , etc.

What I'd really be interested in is one developers version and one  
stable version. From what I've learned today that sounds possible, and  
easily accomplished by installing an Octave.app.

Thanks
Ben