Bug#905469: lintian: Please emit tag on direct access to dpkg database
Hi!
On Sun, 2018-08-05 at 05:37:15 +0100, Chris Lamb wrote:
> > 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.
>
> Ah, neat. I wasn't aware of this proposal and I hope Lintian can help
> get us to that quicker. (Is there a wishlist bug or similar with more
> info about this, just out of interest?)
<https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking#Installed_database>
> > * 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.
>
> Cool. So, some quick questions:
>
> * Are there some existing packages that currently break that we can
> crib as testcases?
Many, starting from codesearch.debian.net, I'm counting on the order of
100 or surroundings, after having downloaded them all and being in the
process of removing false-positives. Here are some examples:
* .list
- python-pyhsm.preinst
- popularity-contest/popularity-contest
- goplay/src/goplay.cpp
* .md5sums
- config-package-dev/dh_configpackage
* .conffiles
- hylafax-server.postinst (this one is in addition doubly bogus,
as md5sums do not contain conffiles)
- geda-symbols.postrm
* .shlibs
- libreoffice/debian/rules
* .postinst
- propellor/src/Propellor/Property/Ssh.hs
- kickseed/setup/hd
- lxc/templates/lxc-debian.in
* /var/lib/dpkg/triggers/ (wow was not expecting this one)
- ca-certificates-mono.postinst (should be a versioned dependency
instead, but some introspection
support from dpkg's side might be
nice)
> * What files should actually be checked? We wouldn't want to fire on
> docs, just as one obvious example.
Right. I think in this case at least all binary packages, in the same
way we are now checking the sensible-utils stuff. Ideally also the
source package, because I've seen bogus usage there, but I fear, that
is prone to many false-positives, and it might be more difficult to
distinguish those there, so perhaps only the source packaging bits?
> * What sort of severity level would you be looking for?
I'd probably distinguish between:
- important: mtree-blockers (.list, .conffiles, .md5sums)
- normal/pedantic: harmful maint-script case, as there's no other
available solution, info as long as it uses dpkg-query --control-path
interface, otherwise warnings (.prerm, .postrm)
- normal: any other general control file
> * Could you write a quick tag description? What you wrote in the
> introduction to this tag would be a good start at the very least.
Ok how about something like the descriptions for these as three new
tags, as a starting point?
,--- .list/.md5sums/.conffiles ---
Info: This file is internal to dpkg, and will disappear and change format.
In addition for .conffiles and .md5sums the contents did not reflect
pathname take overs from other packages.
.
Use the following interfaces instead:
* «dpkg-query --listfiles <package>» for .list.
* «dpkg-query --control-show <package> md5sums» for .md5sums.
* «dpkg-query -W -f='${Conffiles}' <package>» for .conffiles.
`---
,--- .prerm/.postrm ---
Info: This file is stored within the internal dpkg database, and might
get relocated, change storage format, and is not intended to be used
directly by any other programs besides the dpkg suite of packages. That
the current plain text formats and filesystem layout of the database is
administrator friendly is by design, but that does not extend to other
programs.
.
But as there might be cases where these maintainer scripts contain harmul
code that perform irreversible actions that cannot be undone during
postinst, it might be necessary to modify or remove them from the dpkg
database. Even though this is very strongly discouraged, it is currently
acceptabled as an exception, due to dpkg not providing yet any interface
to solve this problem.
.
To get the pathname of those maintainer-scripts use
«dpkg-query --control-path <package> <maintscript>»
which will use the correct admindir, and internal database path. Even
though the --control-path command is deprecated, it is acceptable to
be used for this particular purpose only.
Ref: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_dpkg_be_told_to_avoid_invoking_a_harmful_prerm_or_postrm_from_an_installed_package_on_upgrade.3F
`---
,--- other database files ---
Info: This file is stored within the internal dpkg database, and might
get relocated, change storage format, and is not intended to be used
directly by any other programs besides the dpkg suite of packages. That
the current plain text formats and filesystem layout of the database is
administrator friendly is by design, but that does not extend to other
programs.
.
Hardcoding the dpkg database directory also means these programs and
packages cannot be used with a dpkg configured to use a different
database directory.
.
The supported way to access these files is via the various dpkg
interfaces, such as:
* «dpkg-query --control-list <package>»
* «dpkg-query --control-show <package> <maintscript>»
`---
Thanks,
Guillem
Reply to: