Octave Transition

[Michael Dickens]

I'm almost to the point of making the "Octave transition":

1) moving "octave-devel" (3.6.4) to "octave" (was 3.2.4);

2) making "octave-devel" replaced by octave temporarily, to get folks
currently using octave-devel to move to octave;

3) adding "octave-next" for the current 3.7.7 release (yes: it works
just fine for me on 10.8 and 10.9);

4) updating the octave-1.0 portgroup to honor CC, CXX, *FLAGS (plus or
minus), and allow patching;

5) fixing / updating as many of the octave-* ports as possible;
deprecate those that were integrated into Octave or that require the
Octave 3.4 or earlier API:

 + all octave-* ports will be set to NOT auto-load, because some provide
 functions which shadow built-in Octave functions;

 + deprecated ports, currently: octave-arpack (integrated) and
 octave-graceplot (requires 3.4 or earlier API);

 + not working yet, but probably will: octave-pt_br, octave-java,
 octave-database;

 + not working yet, and will probably be deprecated: octave-ann (might
 require 3.4 or earlier API);

 + All of the other octave-* ports I have updated to the latest version,
 and they install and can be loaded into Octave.  I do not know if they
 function correctly from within Octave.

I expect to complete this transition in the next few days / this week. 
So, if anyone either (1) needs an octave-* port that is not currently
available; (2) needs one of the above listed octave-* ports which is
either being deprecated or likely to be so; or (3) needs octave 3.2 or
3.4: Please provide feedback to me and I'll do what I can to honor your
request.  If anyone -really- needs Octave 3.2 or 3.4, I will consider
creating an "octave-legacy" port, which conflicts with octave,
octave-devel, and octave-next.  I will not create octave32, octave34,
octave36, and so forth, which could be installed at the same time; that
is too much work to maintain. - MLD