[Aptitude-devel] Please review: proposed changes to aptitude error reporting

[Manuel A. Fernandez Montecelo]

Hello,

2012/6/8 Daniel Hartwig <mandyke at gmail.com>:
> For example, aptitude install may fail to download some packages but
> still manage to install others.  In this case a non-fatal error has
> occured (non-fatal because some actions did succeed) and the exit
> status is 2.  However, the exit status of 2 does not indicate that any
> actions did succeed, only that some may have.

Maybe there are some corner cases where it's handy to distinguish
between partial and total failure, but I don't think that indicating
partial failure is useful.  Unless the script invoking it has some
kind of insight of what went wrong (highly unlikely, IMO), it'll need
human intervention to interpret the results.  And, as Roger mentions,
you usually want everything installed, it's a binary thing, so the
extra information would be irrelevant.

In my mind, the only errors that could be possibly useful to
distinguish would be things like transient network failures, where
scripts could decide to use other mirrors, or packages not yet present
in the mirrors despite the indices being updated (there are bug
reports about that), or something like that.  In these cases, at least
one can retry (in the case that the download is incomplete) with some
hope that the previous error would succeed (unlike, say, resolving
package conflicts, which should always render the same result).


> Previously aptitude's exit status was very ad-hoc.  The use of 255 is
> to remaining consistent with the current fatal exit status, however, I
> believe this should definitely be changed to 100 for consistency with
> apt-utils.

Compatibility with apt-utils is good, IMO.

> Many programs use aptitude but find it unreliable due to the current
> poor state of exit status.  I would like to push this out to
> experimental as soon as it is complete, get it tested, and give people

Using --apt-error-codes temporarily (and default to that at a later
date) is an option, or just change defaults and issuing a NEWS about
it to notify interested people.  I don't think that having it in
experimental is very useful.

Apart from that, as said above, I suspect that most people using
aptitude in this way would rely only on a boolean (SUCCESS|FAILURE),
or at most taking into account user-cancelled codes; I don't think
that many people check for the 255 explicitly.  I can be proven wrong,
though :-)

Precisely, since it's unreliable now (and has been for so many years),
I don't think that a change in the number of error code is going to
cause much distress.

> time to update their programs to take advantage for Wheezy (ok, maybe
> first point release :-).

I think that changing the behaviour now, so close to the release,
could be an error (not sure); but changing in a point release would be
kind of pointless (pardon me for the pun :P)... IMO point releases are
for bug fixes, not to introduce any new features (other than full
updates to very dynamic software such as browsers, for example).


Cheers.