Attached is a repository containing two packages: foo, which has a bad md5sum; and baz, which depends on foo.
This can be used to test behaviour in the presence of direct and indirect md5sum errors: ## sources.list deb file:///home/daniel/badrepo-deb ./ # aptitude update # aptitude --allow-untrusted install foo; echo $? ... E: Failed to fetch file:///home/daniel/badrepo-deb/./foo_1.0_all.deb: Hash Sum mismatch 0 # aptitude --allow-untrusted install baz; echo $? ... E: Failed to fetch file:///home/daniel/badrepo-deb/./foo_1.0_all.deb: Hash Sum mismatch 0 # aptitude show baz | grep ^State State: not installed # apt-get -y --force-yes install foo; echo $? ... Failed to fetch file:///home/daniel/badrepo-deb/./foo_1.0_all.deb Hash Sum mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? 100 # apt-get -y --force-yes install baz; echo $? ... Failed to fetch file:///home/daniel/badrepo-deb/./foo_1.0_all.deb Hash Sum mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? 100 It seems that aptitude's download_update_manager automatically attempts fix-missing. This is likely responsible for the lack of error messages and exit status of `0' later on. The curses ui silently fails the download, presents the user with "Press return to continue", then returns to the interface and displays the "Failed to fetch" error. The user could instead be prompted whether to proceed (i.e. via fix-missing then install) when there are download errors. As the OP on #302784 indicates, the default behaviour with exit code of `0' is very disruptive to, e.g., scripts and such which rely on the exit status to know whether the requested action was successful.
badrepo-deb.tar.gz
Description: GNU Zip compressed data
