Bug#959019: lintian: True or false positive for uses-dpkg-database-directly? Checking for a running dpkg by testing for locks on /var/lib/dpkg/lock
Hi!
On Tue, 2020-04-28 at 06:48:21 +0200, Axel Beckert wrote:
> Package: lintian
> Version: 2.68.0
> lintian on aptitude-robot emits (beyond others) these two tags of which
> I'm not sure if they're true or false positives:
>
> W: aptitude-robot: uses-dpkg-database-directly etc/init.d/aptitude-robot
> W: aptitude-robot: uses-dpkg-database-directly usr/sbin/aptitude-robot-session
>
> Actually it is wrong that these scripts access dpkg's _database_. They
> only access respectively check for other accesses of /var/lib/dpkg/lock:
Well yes and no. :) In this case I'd call the dpkg database everything
under /var/lib/dpkg/. When it comes to the locking though, that's
currently a public interfaces for front-ends as documented in
(/usr/share/doc/dpkg-dev/frontend.txt).
> […]/aptitude-robot → git grep /var/lib/dpkg
> aptitude-robot-session:if fuser -s /var/lib/dpkg/lock ; then
> debian/init.d: if fuser -s /var/lib/dpkg/lock ; then
> […]/aptitude-robot →
But then this usage seems rather racy. :)
> So my question (mostly to Guillem, X-Debbugs-CC'ed): Does this file
> really belong to the "internal interface", "the entire dpkg database,
> its layout and files"?
See above, for front-ends that should be fine to use. But
aptitude-robot looks a bit fringy in that sense?
I think the tag got implemented in a very broad way, from the more fine
grained proposal I sent in one of the mails in the original bug report
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905469#17>. But I
think that was fine, because it can be easily overridden in the few
cases where we'd make exceptions for now, and made it simpler to
implement and get out.
> If yes, how do I check with dpkg's tools if dpkg's database is currently
> locked or more generally in use? (And maybe a hint in the lintian tag
> description would be nice. :-)
Ideally aptitude-robot would use something like libapt-pkg-perl or
similar which would abstract the front-end locking. If it does not
support front-end locking then it should also get support for it. :)
> If no, lintian should continue check for "/var/lib/dpkg" in code, but
> ignore all occurrences of "/var/lib/dpkg/lock" before emitting the tag.
>
> Depending on the answer, please either close this "bug report" or adjust
> the severity accordingly. TIA!
Please see the referenced bug. Perhaps some packages could be
grandfathered for now, or the tag description made more detailed,
taking some of the stuff from one of my mails?
Thanks,
Guillem
Reply to: