[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


> 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.


[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: