Modified Portfile for Octave 3.5.90 attached
Lukas Reichlin
lukas.reichlin at gmail.com
Sun Dec 18 01:16:02 PST 2011
On 18.12.2011, at 06:40, Joshua Root wrote:
> 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
I noticed that my messages didn't make it to the mailing list. Sorry. Therefore I pasted them below together with the port file:
> Hi Michael,
>
> I've created a modified Portfile for Octave 3.5.90. I named the port "octave36" just to simplify administration on my machine. It should become "octave-devel", but before we must update "octave" to Octave 3.4.3.
>
> Regards,
> Lukas
>> Because 3.5.90 is just a preview release and 3.2.4 is very outdated. We need at least one working, up-to-date release and that is 3.4.3. Since we don't want to version octave (octave32, octave34, octave36), we use "octave" for the latest official release and "octave-devel" for preview/developer versions. We should finally get rid of octave 3.2.4 (I don't know a single reason why it should be better than 3.4.3) and its outdated packages that noone wants to maintain. Otherwise we are blocking progress and MacPorts is getting more and more useless for serious Octave users.
>>
>> Lukas
>
> I forgot to mention that Octave 3.4 and beyond has its own package manager with automatic downloading which is working fine. We don't need a parallel universe in MacPorts, especially when it is unmaintained.
>
> Lukas
> Yes, I'm happy either way as long as I get ports for Octave 3.4 and 3.6 :-) As I am the developer of the octave control package (version 2.0.0 and beyond, latest version is control-2.2.3 while MacPorts' "octave-control" is 1.0.11 from early 2009), I need the latest official octave release for testing my current releases and the developer snapshots for, ermm, let's call it mid-term developments.
>
> Best regards
> Lukas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 6977 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111218/ac437ea7/attachment.obj>
More information about the macports-dev
mailing list