Re: dkms needs a pre-depends entry (Policy 3.5)
Steve Langasek <firstname.lastname@example.org> writes:
> As Ian has described it, yes: lsb-release is not "installed" until
> after the python-support trigger is run, so dpkg will run that trigger
> before trying to move up the stack and configure dkms. And since dkms
> is not yet configured, nvidia-kernel-dkms won't be configured either.
> The only exceptions would be a bug in dpkg trigger support, or a bug in
> a higher level package manager passing --force-depends to dpkg.
This implies to me that the following information in the python-support
documentation is partially incorrect:
Namespace packages are empty __init__.py files that are necessary for
other .py files to be considered as Python modules by the interpreter.
To avoid this being a problem, python-support will add them
automatically as needed. However, this will be done later than the
update-python-modules call when dpkg installs the package, because
this is, like byte-compilation, a time-consuming operation.
What this means is, if you need a namespace package or depend on a
package that needs it, *and* that you need to use it during the
postinst phase (e.g. for a daemon), you will have to add the following
command in the postinst before starting your daemon:
If you depend on another package that contains a namespace package, the
trigger support plus the dependency should ensure that the other package
is correctly configured before your postinst runs.
I believe the only case where you would need to explicitly run
update-python-modules -p in your postinst is if the postinst's package
itself installs a Python namespace package and needs that namespace
package to be configured before running that action in the postinst. In
other words, the daemon package itself, if it also contains the namespace
module, may need to do this. But if the namespace module is in a
dependency, this should never be needed.
Is that correct?
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>