Hello, 2012/6/8 Daniel Hartwig <[email protected]>: > 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. _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
