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
