Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
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! Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
On Sat, 2019-11-23 at 16:04:33 +0100, Raphael Hertzog wrote: > On Fri, 22 Nov 2019, Guillem Jover wrote: > > That still does not explain why this needs to be done outside the dpkg's > > execution context, though? > > I don't know any point in dpkg's execution context where we are sure that > we will not install/remove other packages later on. Within each dpkg run, this is always known. But I'm not sure we are now talking past each other. As it stands this is using an apt hook, which means a user can still install directly via dpkg and the hook will be obvlivious to such changes. Switching to use dpkg hooks, would improve reliability at the cost of running many more times, as apt still chunks installations. > > Triggers right now should get batched more aggressively than in the > > past. And I'm not quite sure why they would not be preferable to a > > hook which gets executed unconditionally every time, regardless of > > any package unpacking on the interested paths. This is the kind of > > thing triggers were designed to cover. The current way this is > > deployed seems rather iffy to me TBH. > > I'm not opposed to use a trigger based solution but how do you expect it > to work? Watching /usr/share/applications doesn't work as there are > packages that don't provide a .desktop files and where we want to > install our own desktop file when the package gets installed. > > And I don't want to have to modify all packages for which we are shipping > a .desktop file to install. > > 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. Also given that packages are not supposed to Conflict while providing the same pathnames with wildly different interfaces, checking the installed packages in the db could be skipped, even though you still could do that to be extra safe. In the end this does not look much different from say man-db or other triggers that just track whole directories. Thanks, Guillem
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
On Fri, 22 Nov 2019, Guillem Jover wrote: > That still does not explain why this needs to be done outside the dpkg's > execution context, though? I don't know any point in dpkg's execution context where we are sure that we will not install/remove other packages later on. > Triggers right now should get batched more aggressively than in the > past. And I'm not quite sure why they would not be preferable to a > hook which gets executed unconditionally every time, regardless of > any package unpacking on the interested paths. This is the kind of > thing triggers were designed to cover. The current way this is > deployed seems rather iffy to me TBH. I'm not opposed to use a trigger based solution but how do you expect it to work? Watching /usr/share/applications doesn't work as there are packages that don't provide a .desktop files and where we want to install our own desktop file when the package gets installed. And I don't want to have to modify all packages for which we are shipping a .desktop file to install. 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
On Wed, 2019-11-20 at 12:14:44 +0100, Raphael Hertzog wrote: > On Wed, 20 Nov 2019, Guillem Jover wrote: > > > 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 ? > > > > I'm not sure I understand why this is not done say via a trigger > > instead? Also why this script cannot just called within the postinst > > w/o putting it on the background? > > The package provides many desktop files and the associated icons. The > script scans the list of installed packages and installs/uninstalls the > desktop > files corresponding to each package (we have a mapping desktop-file <--> > binary package). The script might use dpkg-divert if the target desktop file > already exists for some reason. That still does not explain why this needs to be done outside the dpkg's execution context, though? > As a long as dpkg is running, we might install/remove packages and it > might affect the set of desktop files to install/remove. Thus doing > it only in the postinst is not a viable option. I didn't mean to imply doing it within the postinst instead of anywhere else, but just instead of in the background. Running it in the postinst is necessary, even with triggers, at least to catch the first run, in case no other package will activate the trigger, or in case this package needs to inject newly updated content. > Also I just want to perform the operation once, after all package > operations have been completed. But path-based triggers are of no help > as I really have to monitor the installation/removal of many packages. > A named trigger would require changes in the hundreds of packages that > can affect the menu. And the reason of kali-menu is precisely because > we didn't want to have to fork hundreds of packages. Triggers right now should get batched more aggressively than in the past. And I'm not quite sure why they would not be preferable to a hook which gets executed unconditionally every time, regardless of any package unpacking on the interested paths. This is the kind of thing triggers were designed to cover. The current way this is deployed seems rather iffy to me TBH. Thanks, Guillem
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
Hi, On Wed, 20 Nov 2019, Guillem Jover wrote: > > 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 ? > > I'm not sure I understand why this is not done say via a trigger > instead? Also why this script cannot just called within the postinst > w/o putting it on the background? The package provides many desktop files and the associated icons. The script scans the list of installed packages and installs/uninstalls the desktop files corresponding to each package (we have a mapping desktop-file <--> binary package). The script might use dpkg-divert if the target desktop file already exists for some reason. As a long as dpkg is running, we might install/remove packages and it might affect the set of desktop files to install/remove. Thus doing it only in the postinst is not a viable option. Also I just want to perform the operation once, after all package operations have been completed. But path-based triggers are of no help as I really have to monitor the installation/removal of many packages. A named trigger would require changes in the hundreds of packages that can affect the menu. And the reason of kali-menu is precisely because we didn't want to have to fork hundreds of packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
Hi! On Wed, 2019-11-20 at 11:28:09 +0100, Raphaël Hertzog wrote: > Package: dpkg > Version: 1.19.7 > Severity: wishlist > User: de...@kali.org > 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 ? I'm not sure I understand why this is not done say via a trigger instead? Also why this script cannot just called within the postinst w/o putting it on the background? Thanks, Guillem
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
Package: dpkg Version: 1.19.7 Severity: wishlist User: de...@kali.org 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 libc62.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 apt1.8.4 pn debsig-verify -- no debconf information
