Rafael Laboissiere wrote:
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?* folajimi <folajimi@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.
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