[Pkg-octave-devel] octave2.9 in sid

[Colin Ingram]

Rafael Laboissiere wrote:

>* folajimi <folajimi at speakeasy.net> [2005-11-23 09:39]:
>
>  
>
>>Colin seems to think that Rafael has taken care of the issue, but
>>Rafael thinks that the project has stalled...
>>    
>>
>
>If Colin is not taking care of the project and if he thinks I am doing
>it, then I can certify that the project is stalled.
>
>So, feel free to take the plunge.  For now, we need a good design, before
>we start the implementation.
>  
>
my bad...I was thinking about the glpk thing.  I've been off the deep 
end lately trying to make this trip happen.  It looks to me that "number 
1" of the original plan[1] has been taking care of[2].  We still need to 
prepare the remain packages that have octave2.1 as a dependence for the 
"smooth" switch i.e. octave-forge.  I haven't been able to think about 
this much  except for checking out what exactly it takes to build 
octave-forge against the two different octave versions.  I agree that 
three packages are needed here (octave2.9-forge, octave2.1-forge, and 
octave-forge-common for example)  but I haven't began looking at the 
exacts of this and I won't until I return to Madison next week so feel 
free (folajimi) to jump right in.  I think this will be a big a project 
that is likely to break the repository how do you all feel about 
branching /package/octave-forge for this transition?

p.s. are the other packages(semidef-oct, matwrap, epstk, gpc, statdataml 
) going to be affected by the api change.  If not can we just make all 
unaffected packages including the new octave-forge-common package depend 
on the octave virtual package.  I guess we could have a dependence that 
is satisfied by either octave2.1 or octave2.9 also.  Maybe we should 
branch the entire trunk?

[1] 
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2005-November/000695.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2005-November/000705.html