On Wed, Apr 04, 2012 at 08:09:31AM +0200, Raphael Hertzog wrote:
> On Tue, 03 Apr 2012, Josh Triplett wrote:
> > As a more optimal solution, packages could register file triggers on
> > appropriate paths in /usr/local
>
> Some packages already do (man-db for example).
True. I just want to make sure they actually get run; if they did,
man-db (for instance) wouldn't need its current cronjob.
> > and dpkg could provide a means for an
> > administrator to manually trigger those triggers after running "make
> > install" or similar.
>
> 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.
Ideally, the same command which ran all the triggers would also update a
database of stat results for /usr/local, and poke the triggers for
anything that changed. However, given that triggers have to support
running spuriously, triggering *everything* seems acceptable for a first
pass. A quick (untested) prototype version:
find /usr/local -exec dpkg-trigger --no-await '{}' \;
dpkg --configure -a
Wrap that in a script with a nice name (like "update-local"), teach
administrators to run it after "make install", and make sure packages
have appropriate triggers, and that could work nicely.
> > This way, rather than the administrator needing to manually run mandb,
> > ldconfig, fc-cache, and various other things, they could run a single
> > command to update all interested packages.
>
> I'm not sure that this command should be part of dpkg. But it seems
> reasonable to improve dpkg so that such a tool can be written on top of
> dpkg.
Fair enough. Mostly I'd like to find a way to get rid of the various
cronjobs and other hacks that work around the problem of noticing when
things change and letting packages react to those changes. And I don't
think that can happen without a standardized solution. dpkg seems like
the right place for at least part of that solution, if not all of it.
- Josh Triplett
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
