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/
