This page relates to 778357, 776152, 696335 and 745735.

This page is about using "apt-get update" in scripts. For this purpose it is important for the script to find out if anything went wrong and what went wrong. Currently it is impossible to figure out whether an "apt-get update" operation finished successfully or whether an error occurred in a machine-readable way that is not affected by translations or typos in the error message or later changes in the human readable error string.

It is also important to note, that what constitutes an "error" depends on the user. Thus, it's important to be able to distinguish between multiple different conditions so that the caller can decide how to handle them.

The current heuristic used by mmdebstrap is to search for this regex in the output of "apt-get update": /^(W: |Err:)/. This is because even when the update fails, "apt-get update" will return with an exit status of zero:

    Could not resolve ''
    Hit wheezy Release
    Reading package lists... Done
    W: Failed to fetch  Could not resolve ''
    W: Some index files failed to download. They have been ignored, or old ones used instead.

Unfortunately, there also exist situations in which a "W:" is legitimate like in the following examples:

Example 1

If the directory passed via "dir::etc::trustedparts" contains files with an unknown format, "apt-get update" produces the following warnings:

    W: The key(s) in the keyring /usr/share/keyrings/ubuntu-dbgsym-keyring.gpg are ignored as the file has an unsupported filetype.
    W: The key(s) in the keyring /usr/share/keyrings/ubuntu-dbgsym-removed-keys.gpg are ignored as the file has an unsupported filetype.

Example 2

When passing "[trusted=yes]" as part of the repository spec, apt will still complain about invalid gpg keys:

    W: GPG error: bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3B4FE6ACC0B21F32

Example 3

    W: Target Packages (main/binary-all/Packages) is configured multiple times in /tmp/debian-chroot/etc/apt/sources.list.d/0000deb822.sources:1 and /tmp/debian-chroot/etc/apt/sources.list.d/0001main.list:5

Even when demoting above warnings to "info", we can probably find conflicting situations where one user considers a certain situation as error while another does not.


Since consumers of "apt-get update" might not only be interested in a global status, because the apt maintainers consider "something was downloaded" as success and because multiple things might've happened at the same time, using the exit code for error reporting might be the wrong approach.

Instead, maybe there is a way to add a switch or config option which either replaces "apt-get update" stdout by a machine-parsable format or which allows the caller to pass a file descriptor that apt can then use to write a machine readable representation about what happened into.