Bug#905469: lintian: Please emit tag on direct access to dpkg database

[Guillem Jover <guillem@debian.org>]

Package: lintian
Version: 2.5.94
Severity: wishlist

Hi!

The entire dpkg database, its layout and files are an internal interface
to dpkg, no program or package (in theory) should be accessing it other
than dpkg itself and any of the dpkg suite tools. While by design the
database is all editable by the admin, that's a supported property
intended and reserved for sentient beings, not for automatic tools,
even though it's not a practice that should be recommended.

AFAIR this was communicated in the past (but cannot find references
now) as part of the multiarch database layout change, and there's even
already a test to detect direct accesses to dpkg's status files.

This is one blocker that is getting in the way of deploying mtree
support as the dpkg database store, because .list, .md5sums and
.conffiles are intended to disappear from under /var/lib/dpkg/info/,
and that will break all these packages and programs.

I think currently the only exceptions that might be allowed are:

  * Any package modifying (harmful) prerm scripts in the database,
    because we do not currently have any way to mark this yet.
    <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_dpkg_be_told_to_avoid_invoking_a_harmful_prerm_from_an_installed_package_on_upgrade.3F>
  * And any frontend that might currently be accessing
    /var/lib/dpkg/info, because libdpkg-dev was neither a PIC library
    until PIE was globally enabled in dpkg, nor did it contain the db
    handling code, which was restricted to the dpkg binary itself.
    I think apt/cupt and similar would be grandfathered for now, until
    both libdpkg-dev contains such support (should come in dpkg 1.19.1)
    and these have switched over.

Anything else, should be:

  * Using «dpkg --status» for package status.
  * Using «dpkg --status» for Conffiles field.
  * Using «dpkg-query --listfiles» for file lists.
  * Using «dpkg-query --control-(list|show)» to get control file
    information.
  * etc, happy to provide more alternatives to current uses.

Thanks,
Guillem