Re: Performance issues on Windows, suggests a MSVC build

[Thomas Weber]

On Mon, Jun 27, 2011 at 12:54:28PM -0400, John W. Eaton wrote:
> 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.

This is non-issue, we will postpone the handling of sonames. It's a
pity, but it doesn't make much sense to accumulate too many changes.

> 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.

No. The move from 3.0 to 3.2 already required active input from several
package maintainers in Debian, some of whom have no connection with
Octave whatsoever - their packages just happen to build .oct files.

I'm trying to simplify things here. If there are incompatible changes,
those other projects will have to adapt their code.


> 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.  

The bugs itself are not a big problem - compared to Octave's size, we
really don't have many.

> |     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. 

Ehm, once I upload a breaking package (I don't say 'broken' for a reason:
some incompatible changes cannot be avoided and I don't see that as
breakage on Octave's part), someone *will* have to deal with the
outcome. And if that someone is another distribution maintainer, it's
not unheard of them to have no knowledge of Octave whatsoever.

> 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.

Yes, it would be nice to have such a package ...

        Thomas