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
