[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#818912: apt-cudf shouldn't exit non-zero if it isn't crashing



Package: apt-cudf
Version: 4.1-4
Severity: minor

Hi,

$ apt install exim4 postfix -s --solver aspcud
[… busy working for a while …]
[ currently a useless apt unmet dependency error ]
E: Sub-process aspcud returned an error code (1)

That isn't what is supposed to happen, the spec says:

"When the external solver is *unable to find a solution* (and is aware
of that), it will write an error to standard output and then exit with
an exit code of 0. An exit code other than 0 will be interpreted as
a solver crash […]"

Correct would be to exit 0 so that apt shows the error message of the
solver rather than a useless own error (= useless as it will report all
unmet dependencies which will be plenty as nothing was resolved
– I would like to change that to something describing that this is a bug
in the resolver and should be reported, but doing that for unsatisfiable
requests would be wrong).

The difference for the user is a bit dubious at the moment so its at
best minor even if its a spec violation as all aspcud has to say for
itself in this case is:
Message: (UNSAT) No Solutions according to the given preferences

And people complain about apt having unhelpful errors in unsat cases… ;)


I am reporting against apt-cudf instead of aspcud as the 'Message:'
indicates that this could actually be formatted as a proper EDSP error
by apt-cudf.


I tried the other solvers in debian ATM as well:
* packup receives signal 13 (SIGPIPE), so exit 1 is "correct" I guess,
  but it does it also on requests which could be satisfied…
* mccs-lpsolve and mccs-cbc both exit 1 with a message suggesting a more
  general problem with them/apt-cudf:
  Message: The solver does not recognize the MISC 2012 optimization language.
  Please specifify the optimization criteria using --criteria-plain


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: