Hi!
On Wed, 2012-04-04 at 03:39:54 -0700, Josh Triplett wrote:
> On Wed, Apr 04, 2012 at 11:43:48AM +0200, Raphael Hertzog wrote:
> > On Wed, 04 Apr 2012, Josh Triplett wrote:
> > > > In some way we already do:
> > > > $ sudo dpkg-trigger --no-await /usr/local/man
> > > > $ sudo dpkg --configure -a
> > > > Processing triggers for man-db ...
> > > >
> > > > But there's easy way to find out all the file triggers that match
> > > > /usr/local/something.
> >
> > I meant "there's no easy way".
> > > running spuriously, triggering *everything* seems acceptable for a first
> > > pass. A quick (untested) prototype version:
> > >
> > > find /usr/local -exec dpkg-trigger --no-await '{}' \;
> >
> > dpkg-trigger will only accept names of existing triggers. That's why I was
> > telling that you would need a way to extract a list of file triggers.
>
> Oh, I see. I would have expected "dpkg-trigger /path/to/file" to
> trigger triggers for "/path/to", not just "/path/to/file". But it looks
> like that doesn't work.
That's been fixed now in dpkg 1.16.4.
> (The find command I suggested should still work, since it'll trigger all
> parent paths as well, so unless a package had "interest /usr" or
> "interest /", it should work. But the more optimized version that only
> triggers on changed files would not work, without explicitly triggering
> all parent directories as well.)
In any case just as a clarification, dpkg-trigger does not do any
significant work, it does not even check if there's matching triggers,
it just queues them so that later on whenever dpkg is run it can
process those triggers, trimming out any that do not match, and
triggering each one only once even if some paths would match several
times.
> > Then you can easily match file triggers with files installed in
> > /usr/local/.
>
> Rather than trying to parse triggers here, why not just add an option to
> dpkg-trigger which says to interpret the argument as a filename,
> precisely as it would when dpkg wants to install/modify a file with that
> name, and trigger any triggers which care about either that name or any
> parent directory?
>
> Thus, while dpkg-trigger /path/to/file only triggers a package that has
> "interest /path/to/file", dpkg-trigger --filename /path/to/file would
> trigger a package with "interest /path/to" as well.
As per above, that's now the current behaviour, but not only for
filenames it applies to any path, including directories.
> (Preferably, dpkg-trigger should take an arbitrary number of filenames
> rather than just one, but that just represents an optimization.)
Here the optimization would only consist of reducing the amount of
calls to dpkg-trigger, but the amount of activated triggers would not
change a bit, so given that this usage does not seem common, I'd rather
not add this. If it really becomes extremely cumbersome or it's shown
to take too much time, then I'd be open to consider this (as a separate
bug report, though).
> Having such an option seems preferable to manually extracting lists of
> existing file triggers and parsing them. In particular, it would also
> work for any future extensions to file triggers (such as more intricate
> include/exclude logic).
So given all the above, I don't see anything else really needed from
the dpkg side, and the proposed update-local could be implemented and
added in some other existing package right away.
As such I think we can close this bug report?
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
