Re: Draft spec for new dpkg "triggers" feature
Joey Hess writes ("Re: Draft spec for new dpkg "triggers" feature"):
> I wonder if you could expand a bit on how this will look if it happens
> in the middle of an apt run performing a major upgrade.
Sure.
> Probably apt will tend to upgrade to the new dpkg early in the run,
> since many packages will depend on it for triggers. This will probably
> happen in a separate dpkg invocation than most of the rest of the
> upgrade, given the way apt works.
The new dpkg will behave just like the old one, and none of the
triggers will run, until right at the end of the installation, apt
will run dpkg --configure --pending, which will run all of the
triggers that anyone is interested in.
There is the difficulty that the upgrade must be done by the new apt
since the old one may get confused by the new `triggered' state. I'm
hoping that it will be possible to get the new apt (which ought to
have only very easily-reviewed and safe changes) into the previous
release's -updates.
> Some other packages might be upgraded
> first, and some of those might activate triggers installed later.
Actually, you can't activate a trigger that's installed later, but I
think this is irrelevant in your scenario.
> Will
> those be the ones that will need the --configure --pending to be
> handled? Or would it only be limited to trigger-defining packages that
> are installed in the same dpkg run as the new dpkg?
No, all trigger-interested packages will have all their triggers run.
If you have a better approach to this I'd be keen to hear it; I don't
like my current design much in this area.
Ian.
Reply to: