Hi!
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.)
> > 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.
> Of couse I'm willing to switch to an alternate mechanism if it provides
> the goal.
The point of triggers is to accumulate some actions that would usually
be performed on the triggering package maintainer scripts, into the
package that provides that functionality, so that no maintscript code
needs to be added for all the affected packages, and so that the code
can run less times.
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 /).
The point is that conceptually this is not the correct interface to
use. You want to hook into when a package is installed or cofigured,
but you are hooking into when a package ships a certain path, but you
don't care about those paths, only about the packages status.
> > If you need to hook into dpkg whenever something gets unpacked/configured
> > etc, please just switch to use invoke hooks instead (please check the man
> > page for further details).
>
> There's surpringly little documentation around about invoke hooks. So
> as far as I can see you suggest to drop a sniplet in
> /etc/dpkg/dpkg.cfg.d/ that defines a post-commit to invoke (via a
> helper script) "/var/lib/dpkg/info/debian-security-support.postinst
> configure", or does quite the same on its own. (Just in case, debconf
> is used which might result in additional hazzle.)
Yes, this is the equivalent of how apt-listchanges and similar hook
into the apt invoke hooks, but at a lower level.
You'd add something like:
,--- /etc/dpkg/dpkg.cfg.d/debian-security-support ---
post-invoke /usr/bin/check-support-status
`---
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.
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.
> 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.
> 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.
> > In addition as a side comment (but maybe I should file another bug
> > instead), please use «dpkg-query -f '${Version}' -W dpkg» instead of
> > using «dpkg --version», which is more future proof.
>
> Thanks for the hint, already taken care of.
Cool, thanks.
Regards,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
