in a clean testing chroot:

Setting up matlab-support (0.0.18) ...
No matlab found and maybe running in non-interactive mode. No way out --
failing...
dpkg: error processing matlab-support (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 matlab-support
E: Sub-process /usr/bin/dpkg returned an error code (1)


also it has dozens of upgrade and installation failures in ubuntu,
probably not relevant for Debian, but it sheds a bad light on the
quality of the package.

Le samedi 09 mars 2013 à 14:18 +0100, Julian Taylor a écrit :
is not present. Otherwise people who install the package by accident end
up with a dpkg error.

Julian: please confirm that it fixes the issue for you.

But should it exit nicely if no matlab is present???
Absent matlab == matlab cannot be supported == error   in my vision of
how things should be handled in this package.  Having it installed
without error should provide some guarantee that Matlab is present so
that dependent packages could rely on that.

If it is in the violation of some statute of the policy -- please
let us know.   Otherwise -- please wait for the main maintainer's
opinion on this issue.

The name and description of the package provide sufficient information
to avoid installation "by accident". And if that happens, it should be
removed then.

in Ubuntu...

Meanwhile, this package in Debian has only following bugs:

    Status
        2 Outstanding
        3 Resolved
        1 From other Branch
    Severity
        1 Serious (policy violations or makes package unfit for release)
        5 Wishlist items
    Classification
        1 Patch Available
        1 Unclassified

including yours, and regular releases -- seems to be not that bad, and
maintained.

If noone can maintain it properly  in Ubuntu -- feel free to drop it there I
guess.  We will address our users issues while they complain via
NeuroDebian channels.

in Ubuntu...

Meanwhile, this package in Debian has only following bugs:

    Status
        2 Outstanding
        3 Resolved
        1 From other Branch
    Severity
        1 Serious (policy violations or makes package unfit for release)
        5 Wishlist items
    Classification
        1 Patch Available
        1 Unclassified

including yours, and regular releases -- seems to be not that bad, and
maintained.

If noone can maintain it properly  in Ubuntu -- feel free to drop it there I
guess.  We will address our users issues while they complain via
NeuroDebian channels.

in Ubuntu we have around 40 reports (which I'm currently duplicating
into one report) from people who install it and get an error message
sometimes their installation even hangs completely, even though I see no
significant difference to in the installation scripts to Debian.
The number of reports almost is about 1/4 of the popcon in Debian.

While we Debian maintainers know how to deal with dpkg failures, average
users don't.
I don't know if it technically violates policy, but its certainly not
acceptable for a distribution not focused on only technical users.
If not fixed removal from Ubuntu is certainly an option, but I'd prefer
to have it fixed in Debian too.

Yes it would be great to have bugs fixed in Debian too, especially if they get reported on Debian systems... as for this particular one I consider it a feature :-)
Keep us updated on what you figure out

Hi,

I see the problem, but I am not convinced this change is the solution.
Installing this package is pointless without Matlab, it should not be
pulled in as a dependency unless
a package gets installed that requires matlab.

If we make this package install successfully on a system without Matlab, we
need to
make any dependent package handle the situation of a missing matlab itself
-- potentially multiplying the effort. At the moment, any package that
depends on matlab-support can expect a functional matlab installation to be
present at config time.

To me the actual question is, why do people try to install this package
when they do not have matlab? Consequently I see two approaches:

1) Improve the package description to avoid this kind of installations.

2) Improve the error messages.

Any input for improvements is most welcome.

I'd be happy to discuss this further, but at the moment I see no reason to
change the current behavior.

Michael

A problem with failing the installation if matlab is missing is that it
prevents migration from Ubuntus proposed repository to the main one.
Migration requires that it installs and does also not make other
packages uninstallable.
E.g. this right now affects dynare, it can't migrate because it depends
on matlab-support which does not install.

I though that the debian unstable -> testing works the same way, but
apparently not as e.g. dynare was allowed to go into testing.
We can change the failing in Ubuntu only if you don't want to change Debian.

The main reason for that is probably that the desktop file says it is
matlab.
The desktop file is used in the (ubuntu) software center to display the
title of the application, not the package short description.
Most novice users install over the software center in Ubuntu, see matlab
and install it without reading the rest of the description.

Software center is also in Debian, but I don't know if it has the same
behavior.

In the context of testing migration, installability is determined by
computing package relationships, not by actually attempting to install
the affected packages (which generally wouldn't add much and isn't
feasible given the number of packages involved).

Regards,

Adam

makes sense, I probably have misinterpreted the britney(?) output.

dynare is not migrating because of an incomplete libmatio transition.
So the failing install is probably no problem.

Am 09.03.2013 19:10 schrieb "Adam D. Barratt" <adam@adam-barratt.org.uk>:

This seems to indicate that Debian is not affected by this problem. I am
not familiar with the way Ubuntu manages these things in detail, but if
there is a way to solve this problem in Debian for Ubuntu I am all for it.

Right now this package causes a problem with an automated transition rule
checker. Making it install under any condition, will cause problems that
affect users. If this is necessary, the patch should at least handle the
situation where matlab-support is installed, but no matlab, and
something/someone wants to use matlab. This could be a dependent package
trying to compile a MEX file. It would need to install some executable that
brings up a meaningful error message, especially when invoked via the
desktop file in an X session.

Maybe it is leaner to handle this package as an exception in the transition
checker. This was done in Debian's piuparts, AFAIK.

Michael

Le samedi 09 mars 2013 à 18:26 +0100, Michael Hanke a écrit :

Removing patch tag as a consequence.

I confirm this for dynare-matlab which currently assumes that when
matlab-support is correctly configured, there is a working MATLAB
installation.


I think we should first decide whether this issue is RC (because of
Wheezy to be released soon), and this is indeed not obvious. It is of
course expected that packages in "main" install fine in noninteractive
mode and in a clean chroot. But matlab-support is different since it is
in section "contrib" and is useless without some nonfree program
(MATLAB) not present in Debian; in some sense MATLAB is a implicit
dependency of matlab-support, so the current behavior also makes sense.
Maybe the Release Team has an opinion on the RCness of this issue?

Le samedi 09 mars 2013 à 22:03 +0100, Sébastien Villemot a écrit :

I am lowering the severity of this bug. Since it only affects users who
don't have MATLAB (and who are therefore not the primary target of this
package), I think it does not make the package unsuitable for release.

I nevertheless hope that we will find a solution to the Ubuntu testing
migration problem.

If it is ok with debian policy I am also ok with closing the bug.
The Ubuntu testing migration is of no concern to Debian, and most likely
not related to matlab-support but a different Ubuntu problem (an unwise
incomplete libmatio transition).
It would be nice to change the desktop file to state something like
Matlab Integration instead of just Matlab to avoid the problem in
.desktop based software centers (assuming debian software center behaves
the same way).


I also want to apologize for the remark on the package quality. It was
unwarranted, not productive and just essentially showed that I did not
do my homework properly.
Sorry, I'll try to be more respectful and thorough in future.