Quoting Patrick Schleizer (2015-02-14 01:40:43) > When "apt-get update" fails the program under some conditions exits with > a 0 status. It would be useful if it exited with a non-zero status in > that case (or if there were a switch to tell it to do so). > > Since there is already... > > - provide meaningful exit codes for network failures > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776152 > > and > > - apt: Provide meaningful exit codes for gpg failures > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735 There is also #696335 which was merged with #776152. > That have been found more or less by trial and error... I am wondering, > if there are any other situations, where this could happen. > > Perhaps while you're at #776152 and #745735, could you please check if > there are other cases, where apt-get exits with a 0 status, where it > should exit with a non-zero status? Since this bug saw some activity recently I wanted to chime in and describe what I did in mmdebstrap which also calls "apt-get update". To figure out whether apt-get update succeeded or not, mmdebstrap checks the output for this regex: /^(W: |Err:)/ If there is a match, then the update probably failed. Since warning and error strings are supposed to be human readable (also think of translations) there is no way to reliably figure out what went wrong. Even if the error was only transient, I need a way to figure out that there was an error. Without knowing that, I don't know whether I should re-run apt or whether I should re-run it in a different way or whatnot. What stops apt from returning exit codes like this: 0 - everything is fine 1 - error condition A 2 - error condition B 3 - ... If apt is executed by a user on the terminal, a non-zero exit code does not bug them. But if it's executed by a script, there is now a clearly documented way for the script to decide what went wrong if anything. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature