Guillem Jover wrote... > On Sun, 2014-10-26 at 20:01:22 +0100, Christoph Biedl wrote: > > Guillem Jover wrote... > > > > > Control: severity -1 serious > > > > Why? > > Well, because as it stands, it creates trigger cycles, so I don't think > it is fit for release. (Those cycles started to get detected recently, > then that regressed and stopped being detected, which meant that Jakub > closed the other RC bug, but now should be detected correctly again.)
Ah, that one. I thought it had been dealt with, nevertheless if you consider that kind of trigger usage a bad idea, let's get rid of it. > > > Actually, besides creating triggers cycles, this seems rather an abuse > > > of triggers. Because what the package seems to want is to be notified > > > when any package is unpacked. This is really not what triggers where > > > intended for, even if they "allow" this kind of usage. > > > > There was no indication for me at all you consider this abuse. > > I'm not sure if you mean in general, like in documentation or > previous posts about this, or if you mean in the above comment, if the > former I'll gladly try to improve the documentation, or write a post > to say debian-devel to state that clearly. If the latter, I'll try to > explain below why anyway. Actually the latter but this deserves broader knowledge anyway. An updated version will be uploaded in a few minutes, Just some comments: > In this case you want dpkg to trigger for every and each package > installed, and you are assuming all packages ship at least a file > under /usr (in practice this might do the job, but you'd really want > would be to trigger on /). Being sophistic (but not serious), /usr/share/doc/ should be sufficient due to policy 12.5 "Copyright information" :) (...) > Please do not access the dpkg database on the filesystem directly, > and move the functionality into a new script, or update the existing > one to do the equivalent. Did so. I was thinking of invoking dpkg-reconfigure instead but that might cause nasty effects due to dpkg nesting. > And I don't think that using debconf outside of a maintainer script is > a problem TBH, but you might want to check with the debconf maintainers. Don't think so, although lintian is a bit unhappy. > > This sounds a bit weird. And creates a problem: Even if I check > > $DPKG_HOOK_ACTION for "configure", this hook will be called for each > > package if more than just one is being installed. This will increase > > load on my side unless there's a way to to detect the *last* > > "configure" invocation of a dpkg run in a sane way - that's the job > > the trigger served very well. > > The hook is executed per dpkg run, not per package action, so if apt > bundles say 40 packages in a dpkg call, then there will be only one > post-invoke execution. The problem is that if apt does multiple dpkg > runs, because for example it is dealing with Essential packages, then > yes it will be called multiple times. But the same applies to a > trigger as dpkg might end up calling it multiple times depending on > when it gets processed, or when it subsequently gets triggered. As things just happen, my observation above was the result of an unlucky test scenario where I saw several hook invocations. But there were also several trigger invocations, so there is no differences. > > Please confirm this approach or suggest a better one. > > Yes, that should do the trick. You can easily check how this behaves > on your system by adding something like: > > ,--- /etc/dpkg/dpkg.cfg.d/10-post-invoke --- > post-invoke "echo Dpkg hook action: $DPKG_HOOK_ACTION" > `--- > > But, let me know if anything is not clear, etc. A heads-up: Trailing spaces in that post-invoke line might result in completely mis-leading error messages. Will investigate further and perhaps file a bug report about that. Thanks a lot for your explanations. It was insightful and I love to learn from people who are willing to share their knowledge in a patient way. Christoph
signature.asc
Description: Digital signature