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/
