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
