Your message dated Sat, 1 Feb 2020 19:04:35 +0100
with message-id <[email protected]>
and subject line Re: Bug#945131: dpkg: implement a way to wait to detect
whether dpkg is running
has caused the Debian Bug report #945131,
regarding dpkg: implement a way to wait to detect whether dpkg is running
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
945131: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945131
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.19.7
Severity: wishlist
User: [email protected]
Usertags: origin-kali
I just got a lintian warning "uses-dpkg-database-directly" on a script I
wrote a long time ago:
https://gitlab.com/kalilinux/packages/kali-menu/blob/kali/master/update-kali-menu
It's a script started in a postinst and/or in a DPkg::Post-Invoke hook. It
waits until dpkg is no longer running and then perform some work
(involving dpkg-divert to replace some files by our own).
In order to wait until dpkg is no longer running, I try to grab the dpkg
lock... and thus I have hardcoded /var/lib/dpkg/lock and lintian is not
happy.
To achieve this in a more elegant way, could you possibly implement some
"dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or
something similar ?
-- Package-specific info:
System tainted due to merged-usr-via-symlinks.
-- System Information:
Debian Release: bullseye/sid
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500,
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.8-2
ii libc6 2.29-3
ii liblzma5 5.2.4-1+b1
ii libselinux1 2.9-3+b1
ii tar 1.30+dfsg-6+b1
ii zlib1g 1:1.2.11.dfsg-1+b1
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 1.8.4
pn debsig-verify <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On Wed, 2019-12-18 at 09:30:16 +0100, Raphael Hertzog wrote:
> On Wed, 18 Dec 2019, Guillem Jover wrote:
> > > We could add hundreds of path-based triggers, one for each binary that we
> > > reference in our desktop files but we would likely miss any path
> > > change... and it would be a bit tedious to maintain.
> >
> > I checked the kali package, and the solutions that came to mind were to
> > use path-based triggers either on each executable, or just on the PATH
> > directories. The first has the problem that you mention about moving
> > directories, but the second does not.
> >
> > Then instead of looking up these in the dpkg database you could search
> > the PATH for the programs, because that's what the .desktop files depend
> > on anyway.
>
> Indeed, thanks for the suggestion!
Given that I've seen that you have implemented this in the kali
package, I see no reason for this request anymore, so I'm closing it
now.
Thanks,
Guillem
--- End Message ---
