[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bash-completion with triggers

On Thu, 7 Apr 2011 15:16:20 +0200, Raphael Hertzog wrote:

> Hi,
> On Thu, 07 Apr 2011, David Paleino wrote:
> > Hello everybody,
> > I've implemented a new revision of bash-completion, which uses
> > debtriggers(5) to load only relevant completions, and symlink them when
> > something touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so
> > on.
> > 
> > For this to work, the completions have been moved out from /etc/ -- they
> > would be in /usr/share/bash-completion/completions/,
> > but /etc/bash_completion.d/ is being kept not to break tons of other
> > packages installing files there.
> > 
> > However, I'm writing to get comments about the triggers issue. When a
> > package installs an executable in one of the above directories,
> > bash-completion's postinst removed all symlinks
> > in /etc/bash_completion.d/triggered/, and re-creates them. The speed of
> > such operation varies greatly depending on the installed packages -- on my
> > system, it takes about 10s -- but the shell loading seems much faster too.
> > 
> > Is there any objection to bash-completion using triggers to "watch" the
> > aforementioned directories?
> I feel uneasy about this. It means the trigger is going to be activated
> for any package installation and all packages are going to be put in
> triggers-awaited state.

"Only" those installing executables in these directories:

$ cat debian/triggers 
interest /sbin
interest /usr/sbin
interest /usr/local/sbin
interest /bin
interest /usr/bin
interest /usr/local/bin
interest /usr/games
interest /usr/local/games

> The trigger is going to happen very often (like the man-db one) and
> with a 10s impact it's very noticable...

That's on my system, heh :)
(for comparison, it's faster than other triggers here. You might want to try
yourself, package at [1] -- beware, lots of messages regarding removed

[1]: http://people.debian.org/~dapal/debs/bash-completion_1.3-2_all.deb

Unfortunately, I have to remove and re-create all the symlinks upon trigger
activation: in fact, only the directory name is being passed (/usr/bin); if
my postinst had passed the file name activating the trigger (/usr/bin/foo); it
would really be much faster.

> Even if we change apt to actually keep trigger processing to the end of
> the APT run, I fear that the dependency resolution logic is going to
> force the trigger to run sooner and more often because a package
> in trigger-awaited status does not satisfy the dependencies.
> If file triggers could also specify the --no-await option that
> dpkg-triggers supports, things might be different.

That would be great; ideas how to do it?

> But in the current state, I think it's a bad idea to use file triggers
> in your case.

A named trigger isn't better in any case, I believe.

> You'd better use some apt hook to do the task you envision. A file
> trigger that is activated for a majority of package installation is
> probably better dealt with such a solution.

Which hook would you suggest?

Reading apt.conf(5), I find: Dpkg::Pre-Invoke, Dpkg::Post-Invoke and
Dpkg::Pre-Install-Pkgs. I think the first two are run at each unpacking (thus
are unsuitable to me, it would be much slower than now), and the latter is
_before_ installing packages.
Why there's no Dpkg::Post-Install-Pkgs? :)

I believe that passing --no-await for file triggers, or letting the maintainer
specify that in debian/triggers, would be the best solution.


 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

Attachment: signature.asc
Description: PGP signature

Reply to: