Re: dkms needs a pre-depends entry (Policy 3.5)
Russ Allbery writes ("Re: dkms needs a pre-depends entry (Policy 3.5)"):
> Bernd Zeimetz <bernd@bzed.de> writes:
> > Lets remove all triggers from dpkg then.
>
> For things that have to run to make the package usable, yes.
No.
> I prefer packages to work after they've been configured. Otherwise,
> Depends doesn't do what it's supposed to do.
Packages which are awaiting trigger processing are not "configured"[1]
and do not satisfy dependencies. Triggers-supporting tools (which
includes those in lenny) always try to process triggers just as hard
as they try to do other configuration steps.
>From the triggers spec:
Status Pending Awaited Satisfies Remedy
triggers triggers Depends
unpacked never maybe No postinst configure
c.-failed never maybe No postinst configure (when requested)
t.-awaited yes always No postinst triggered + fix awaited pkg(s)
t.-awaited no always No fix awaited package(s)
t.-pending always never Yes postinst triggered
installed never never Yes n/a
> Triggers are great for things that aren't required for the package
> to function (updating the man database, updating the doc-base index,
> registering newly-installed fonts with other subsystems), but if an
> action is required for basic package functionality, I don't think
> you can safely use triggers.
I intended to allow you to safely use triggers even for those cases.
(Obviously not for the essential functionality of an Essential
package, but that has to be always available anyway.)
> > Also adding update-python-modules -p to a postinst script does not hurt,
> > even when dependencies change.
I'm not sure I understand the Python situation well enough to give an
opinion about it.
Ian.
[1] Well, strictly "configured" isn't a term with a well-defined
meaning for dpkg, but loosely we mean "configured" to mean "not just
unpacked, half-configured, or some other state that involves the files
being on the system but the package not working" .
A package awaiting trigger processing (that is, a triggering package
which has activated a trigger in some other package but the other
package's postinst hasn't been run to deal with it yet) are not in
state "installed", even though its own postinst has completed.
The _triggered_ package may satisfy dependencies, but that makes
sense. If a python addon module triggers python, then the module is
not working properly until the python trigger has been dealt with, but
the rest of python is.
Reply to: