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 conffiles) [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. Kindly, David -- . ''`. 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
signature.asc
Description: PGP signature
