Re: Performance issues on Windows, suggests a MSVC build

[John W. Eaton]

On 27-Jun-2011, Jordi Gutiérrez Hermoso wrote:

| As you can see, since Debian builds on 9 architectures or so, we have
| to make sure it builds on those. For the moment, this involves
| dropping debugging symbols and some MIPS-specific hacks. I'm reading
| through the file and I'm also seeing several references of how things
| changed peculiarly to the 3.0 series. We also have a legacy layout of
| having separate 3.0 and 3.2 packages back when it made sense to have
| several versions of Octave packaged for Debian for whatever reason.
| There are plans to drop that, and uniting the packages under a generic
| "octave" package will involve some work.

OK, so some cruft has built up over time.

| Some months ago Thomas Weber and others discussed the plans for an
| updated packaging:
| 
|     
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2011-February/007699.html

I see the git issue as separate, and I would not let that hold up
packaging for a new release.

I may not understand all the details, but it seems to me that the
library soname thing should be easier to deal with now that Octave is
using the method recommended by libtool.

As for the package version thing, I don't know what is best.  It would
be nice to be able to drop the version number from the package name,
but it would also be nice to allow people to install more than one
version since sometimes we have broken things going from one version
to the next and having both octave3.2 and octave3.4 would make it
easier for people to switch between versions, or have both installed,
at least until any problems that come up with backwardly incompatible
changes can be fixed.

| It's not just a matter of sorting out dependencies. We also have
| several bugs to ponder:
| 
|     http://bugs.debian.org/octave3.2

For any of those bugs that are not about packaging, but are bugs in
Octave itself, I suggest that you open a bug report in the Octave
tracker and close them in the Debian tracker.  I don't see it as the
responsibility of the Debian project to track bugs for Octave.  I
think all you should have to worry about is packaging.

| We have to see how this will impact all of the Octave-Forge packages,
| and any other Debian packages that depend on Octave:
| 
|     address@hidden:~$ apt-cache rdepends octave3.2 | grep -v octave | sort | 
uniq
|     dynare
|     education-mathematics
|     fsl-4.1
|     med-physics
|     pfstools
|     python-scitools
|     science-mathematics
|     science-numericalcomputation
|     science-robotics
|     sdpam
|     shogun-elwms
|     xmds

I guess you can't know for sure what will happen until you try it.  It
seems that it would be better to get an Octave package in unstable (or
even experimental) quickly, even if it doesn't build on some
architectures, or breaks other packages.  Waiting until things are
perfect usually means waiting forever.

| I imagine similar things must happen for Windows, or that it has
| packaging complications of its own. My overall point is that just
| ensuring the thing builds isn't enough.

OK.

Thanks,

jwe