Modified Portfile for Octave 3.5.90 attached

[Joshua Root]

On 2011-12-18 05:14 , Michael Dickens wrote:
> OK, so "the facts":
> 
> * we have a new portfile for octave-devel, bumping it to 3.5.90 (i.e., 3.6 beta);
> 
> * octave itself is an old stable version 3.2.Y;
> 
> * octave-devel is the current stable version 3.4.X;
> 
> * octave-FOO packages are unmaintained, and will work primarily only with the current octave port;
> 
> * if we move the octave-devel port to octave, then most if not all of the octave-FOO package ports will not function.
> 
> * octave 3.6 is going to be released soon, and it should become the new octave-devel;
> 
> Hence, we have 2 primary options:
> 
> 1) Try to preserve the functionality of the current 'octave' and it's octave-FOO package ports.  For example, we could leave 'octave' as it is, rename 'octave-devel' to (e.g.) 'octave34', and then bump 'octave-devel' to 3.5.90 -- and, make the various versions conflict with each other.  This would keep the current package ports functional given the old stable version of octave, as well as make the newer versions available, but without octave-FOO package ports.  Keeping 'octave' as it is today around allows anyone using that port to use the packages as well, just as they are today. And, assuming the octave-FOO package ports do work with the current octave, then they will probably continue to do so in the future.
> 
> 2) Move the current octave-devel to octave, and bump the new octave-devel to the 3.5.90 version.  Forget about the functionality of the octave-FOO package ports; wait for actual requests to come in for specific package ports before fixing them.
> 
> As Andrea said, we hate to delete functional ports -- in this case, then octave-FOO package ports; I think we all would prefer -any- port to be reasonably functional, whether actively maintained or not -- as opposed to intentionally breaking it.  Although I'd prefer to do "out with the old, in with the new" via (2) above (it -is- that time of year, right), I'm more inclined to do (1) since it maintains the status quo while providing new and updated ports for those wanting the latest.
> 
> I think there's been enough discussion, and we just need to decide the path to go down.  Shall we do "majority vote", or what?  I think Lukas will be happy either way, so long as he gets his Octave 3.4 and 3.6 ... :) - MLD

I'd suggest making an octave32 port copied from the current octave and
updating octave to 3.4, leaving octave-devel as the latest development
version as is the intent for -devel ports in general. Then make all
octave-FOO replaced_by octave32-foo.

If in future some of the packages are updated to work with 3.4, their
portfiles can just be updated and the replaced_by removed.

- Josh