[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: additional packages

From: Ben Abbott
Subject: Re: additional packages
Date: Fri, 29 Feb 2008 18:51:43 -0500

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

Ben Abbott schrieb:
On Friday, February 29, 2008, at 03:52PM, "Thomas Treichl" <address@hidden > 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 is installed?

Fink doesn't know anything about even if it is installed and therefore Fink can't use any of's libraries. doesn't use Fink's libraries but uses it's own ( 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 both on one and the same machine can use both without conflicting or damaging each other (maybe they can't use 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?!


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. isolates from system paths - that's why Fink doesn't see anything from - and uses it's own system paths - that's why Fink doesn't conflict
Do you mean to imply that 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 that there is no problem?

Correct. If finds in /Applications then always is used - you can install so many gnuplots as you want somewhere else on your Mac, they are all ignored. Further, 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 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 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 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 installed, this time if we use the -global option for pkg.m, then Octave-Fink packages should go somewhere into / sw/... and packages should go into /Applications/

The global option will work fine provided the versions of Octave are compatible with the packages, 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'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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]