Re: Draft spec for new dpkg "triggers" feature
* Ian Jackson <ian@davenant.greenend.org.uk> [070201 14:00]:
> We don't have any triggers yet, so I don't understand how you can say
> that they "can become quite a hassle".
Bad memories from (mostly looking at others) use of Yast (I don't know
where those functionality lives, could also be some levels under it),
where whenever something is changed or installed, one has to wait some
time for some triggers to run. It might not be that long, and not that
often, but if you don't know what is going on (I think on Suse systems
I can include myself in that group easily), it gets extremly annoying.
> > And allowing packages to just listen for some file or directory feels
> > like encouraging half-backed solutions.
>
> It reduces the amount of stuff that needs to be precisely coordinated
> between different packages; explicit triggers need the trigger names
> to be coordinated as well as everything else.
Well, everything else should need to be coordinated as well. Just
setting a trigger name is then the least of the problems.
> > > A file trigger is guaranteed to be activated before the file in
> > > question is modified by dpkg; on the other hand, a file trigger might
> > > be activated even though no file was actually modified.
> >
> > What does that garantee? That no modification can be missed if dpkg
> > is interupted before finishing?
>
> Yes.
>
> > What's the advantage in doing so?
>
> It will avoid situations where the interested package is broken
> because (for example) some data it previously registered has
> disappeared.
How? Would it suffice to garantee it triggered before the package
comes from the working to the non-working state or vice versa?
This way the trigger might be run unnecessarily when the files it runs
on are in a inconsistent state, causing error messages and warnings
without need.
> Since triggering is idempotent, the concept "too often" seems
> irrelevant, really.
Well, I strongly disagree. Especially if it encouraged to act the
same to all triggers, I need no crystal ball to foresee packages
doing a full reconfigure when any directory they are remotely
involved in gets any action.
> > I'd also prefer a way so that if programs get better they can avoid
> > work in the future, if only some updated have to be done depending on
> > what changed. Like when only a new menu-provider appears for
> > update-menu, there is no reason to recreate all menus, but only the
> > one that is new. Or some other program could detect that only some file
> > vanished and could just remove all information for that package without
> > reparsing and reprocessing all information.
>
> This can be done using file timestamps.
Time stamps means second-guessing. Getting that work portably is not
that easy. (Especially as dpkg sets the most visible timestamp to
be that from the package for normal files).
> > To avoid being something like that impossible by design, having a way
> > to specify a trigger happened and the names of the packages (or other
> > free-form data given to a explicit trigger call) handed to the trigger
> > processor.
>
> I thought about something like this. But it makes activating a
> trigger no longer idempotent (because of this additional data which
> needs to be carried about), and it will also be quite cumbersome to
> constantly have to record and pass about the ancilliary data.
I think the idempotency is not that much of a trouble (if a package
cannot guarantee to have it idempotent if only stuff in the specified
packages changed, it can just ignore the information). The storage of
the information might be a bit more of a hassle. (Especially as it might
more easily be more than a command line length than the number of
triggers triggered).
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: