Re: Speeding up dpkg triggers with a list of changes

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2012-10-22 at 20:24:33 +0300, Kari Pahula wrote:
> I tried out using inotify to speed up dpkg file triggers, with man-db
> as a test case, not that this approach is limited to that.

> I'd say that doing this is a worthwhile thing, but I'd like to discuss
> the specifics.  How closely should this be associated with dpkg
> itself?  Starting the collection process takes about 200ms so I'm not
> quite sure how well launching it at the same time as dpkg itself would
> work.  With apt-get or aptitude that'd pose no problem.  On the other
> hand, man is an example where we could eliminate that delay if we
> applied some domain specific knowledge.  Stop readdir early if there
> are any non-directories in a directory, since we know that, for man,
> none of those will have subdirectories.  We're only adding inotify
> watches on directories.

If this was desired, dpkg already has all information needed, as it's
the one triggering those events when going through the tarball being
extracted, there's really no need for inotify or the equivalent on
other kernels (kqueue on most BSDs for example, or the native file
and dir notify support on GNU/Hurd).

There's the problem of passing a possibly too large list of files on
the command line, and of most things being triggered not being able
to make use of that list anyway. In principle I don't think this is
generally useful.

In the specific case of mandb I'd rather just try first to make the
interest more fine-grained (say one per manN subdir), and changing
mandb to accept subdirs. I think that could improve the current
situation quite a lot w/o other major changes (except for mandb
itself, but it would need to be changed anyway to get a list of
files, so...).

thanks,
guillem