[Pkg-octave-devel] Addressing some bug reports

[Rafael Laboissiere]

* Thomas Weber <thomas.weber.mail at gmail.com> [2008-04-15 16:04]:

> Am Dienstag, den 15.04.2008, 12:42 +0200 schrieb Rafael Laboissiere:
> > Some bug reports have been put on hold while we were busy with the
> > suitesparse/hdf5 transition, the octave2.9 removal, and the octave-forge
> > pkgs upload:
> > 
> >     #420079: octave3.0 needs mkoctfiles
> >     #420080: Merge octave3.0 and octave3.0-headers packages
> 
> Merging the packages means pulling in every single -dev package we need
> during build in end users installation, otherwise neither pkg.m nor
> mkoctfile will work. This is *a lot* ...

In the discussion around these bug reports, it seems we have reached
consensus on moving pkg.m into octave*-headers [1].  Is this okay with you?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420080#24

> On second look, maybe it's not that much (about 100MB), but I think we
> are missing some -dev packages in octave3.0-headers (qhull-dev, ...).

Are these *-dev packages really needed?  I think we should make
octave3.0-headers depend only on libraries that appear in "-l*" options in
the mkoctfile script.

> In the long term, it would be worthwile to change mkoctfile to not link
> self built .oct files with every library. I don't know if this is
> actually feasible, but the current setup triggers difficult to find
> bugs:
> If you upgrade a library and the distribution upgrades your octave
> installation, your self-built .oct files will stop working, with no
> error message whatsoever:
> https://bugs.launchpad.net/ubuntu/+source/octave3.0/+bug/204717
>
> We had the same problem in Debian, where I think the hdf5 transition was
> the culprit (octave linked against the new hdf5 library, whereas octaviz
> was still linked against the old one).

Agreed.  The current dpkg-shlibdeps already issues several warnings like
this:

dpkg-shlibdeps: warning: dependency on libhdf5-1.6.6.so.0 could be avoided if "./build/Common/vtk_init.oct" were not uselessly linked against it (they use none of its symbols).

> > #460812: octave-doc, octave-info, etc. should be actual packages
> Same problem as with an octave package: which package should they point
> to and who decides about a switch later (as happened from octave2.1 to
> octave2.9)? I'm not against this in any way, but I see simply no good
> solution to this.

Agreed, but we must take some action, either closing or tagging "wontfix"
this bug report.

-- 
Rafael