Dear Thomas andCarnë ,
>
> Are there confirmed reports that those packages do not work
anymore in
> recent versions of octave?
This approach doesn't work. We had Octave in Debian seg-faulting at
startup on some architecturves for *years*. As nobody was using the
software at all on these architectures, no bug about this was *ever*
reported.
That a package produces a segmentation fault on a rarely used
architecture can also happen with a actively maintained software. If no
one use the package on a specific architecture, how could the
maintainers know that there is a problem?
Some packages are also simple script files. For example I use the
mapping package for years and I never had a problem with it. There is no
additional feature of this package that I would need. I am fine with the
fact that there has no release since 2009.
To improve code quality, I would rather suggest to ask the maintainers
(if they can be reached) to add a test script to their package which
verifies the functioning of the package as a whole (e.g.
test_<packagename>.m). This script could call for exemple the test code
the individual file with the test function but it would also check if
the functions work correctly together. I can write such a test script
for mapping. If a package fails its test suite, then we have, in my
oppion, a more objective way to decide that this package should be
removed from the "official" list of packages.