retitle 598076 apt-listbugs: please enhance safety in case of network problems, when stdout is not a terminal severity 598076 wishlist thanks
On Sun, 26 Sep 2010 10:11:09 +0200 Mario Barchetti wrote: > Hi, Hi and thanks for your bug report! > > Yesterday I ran "aptitude --assume-yes --download-only safe-upgrade" and then > "aptitude --assume-yes safe-upgrade", redirecting standard output and > standard error to a file, and I got this: > > Reading package lists... > Building dependency tree... > Reading state information... > Reading extended state information... > Initializing package states... > Reading task descriptions... > Resolving dependencies... > The following packages will be upgraded: > grub-common grub-pc libc-bin libc-dev-bin libc6 libc6-dev libc6-i386 > locales python-central python-support xserver-xorg > 11 packages upgraded, 0 newly installed, 0 to remove and 19 not upgraded. > Need to get 0B/19.3MB of archives. After unpacking 532kB will be used. > Writing extended state information... > Fail > Error retrieving bug reports from the server with the following error message: > W: getaddrinfo: Name or service not known (http://bugs.debian.org:80) > It appears that your network connection is down. Check network configuration > and try again > Reading changelogs... > Preconfiguring packages ... > (Reading database ... > [CUT] > > > There were some bugs affecting grub-pc, grub-common and also xserver-xorg, > but the upgrading has worked anyhow, [...] > So I think that apt-listbugs returns zero, instead of a non-zero exit status, > if an error happens retrieving bug reports from the server. I am able to reproduce the behavior you obtained. If I am not mistaken, what happened on your system is the following: * you ran aptitude safe-upgrade with standard output redirected to a file, hence apt-listbugs had its standard output not connected to a terminal * as explained in the man page, this causes apt-listbugs to assume "no" as the answer for each question: [...] | ยท -n | --force-no Assumes that you select no for all questions. | This option is assumed if stdout is not a terminal. [...] * your network was down or otherwise not functional, when apt-listbugs attempted to connect to the BTS SOAP interface in order to retrieve bug data * apt-listbugs would have asked the following question, if its stdout had been a terminal: Retry downloading bug information?[Y/n]? * since your stdout was not a terminal, a "no" answer was assumed * next question would have been: Abort the installation[Y/n]? * once again, a "no" answer was assumed * as a consequence, the installation went on regularly So, in summary, it seems that apt-listbugs behaved as documented. I can acknowledge that maybe this behavior is not the safest way to deal with network problems on unattended operations... Maybe, that "Abort the installation[Y/n]?" question could be turned into a "Continue the installation anyway[y/N]?" ... Do you think this could be a good idea? -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpvffE1Qs625.pgp
Description: PGP signature
