Status: draft

There is currently no way to mark a package as tainted when some dangerous actions are performed on them, or to track that they had some bogus metadata and perform heuristic sanitizing actions to clean those up without forgetting that these might have been wrong.

The prospective name of the field in the dpkg status database could be «Dpkg-Tainted», namespaced to avoid possible conflicts with pre-existing fields used in the wild.

When an action on a package is under the influence of some --force- options, it would be nice to mark those packages as being tainted, so that the admin can later on check what might need to cleaned up, or for reportbug to include such information so that maintainers know that something else might be going on in the system.

When fixing up historic package metadata that used not to be a problem before, but where dpkg is now stricter, such as missing Architecture fields, it would be nice to be able to fill those up automatically, even if doing so with a best effort approach. In this case we could assume the missing Architecture field to be the native arch, and mark it as «Dpkg-Tainted: synthetic-arch» for example.

Some of those tainted markers could be cleared when the package is upgraded to a version that does not have the problem anymore, for example a package with an explicit Architecture field, or a package upgraded without any force flag.

Teams/Dpkg/Spec/TaintedDatabase (last modified 2016-08-31 02:46:45)