Re: dkms needs a pre-depends entry (Policy 3.5)
On 2010-07-20, Bernd Zeimetz <bernd@bzed.de> wrote:
> On 07/18/2010 02:35 AM, Ben Hutchings wrote:
>> On Sat, 2010-07-17 at 17:03 +0000, Philipp Kern wrote:
>>> On 2010-07-17, Ben Hutchings <ben@decadent.org.uk> wrote:
>>>> The postinst for nvidia-kernel-dkms invokes dkms, which invokes
>>>> lsb_release. lsb_release hasn't been configured at this point so its
>>>> module has not been installed for the default Python version. But I
>>>> agree that there is no need for Pre-Depends.
>>> Quoting `/usr/share/doc/python-support/README.gz':
>>> | 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:
>>> | update-python-modules -p
>> Then this is a bug in python-support. If A depends on B, then A should
>> not need to know whether B depends on C (which may well change over
>> tme).
> Lets remove all triggers from dpkg then.
Polemics are not helpful.
> Updating the Python modules for every new module package is a big waste of
> time, running it as a trigger results into the described problem in a few
> rare cases. What do you prefer? Also adding update-python-modules -p to a
> postinst script does not hurt, even when dependencies change.
Well, I noticed the case mostly when trying to start a daemon written in
Python from a package's postinst, while the package also ships modules
needed by the daemon.
In this case, in order to get the binary useable, `update-python-modules
-p' has to be run. This case I find acceptable, albeit non-obvious at
first. (But then you need to know your toolchain anyway to package
something properly.)
On the other hand here it is a tool that happens to be written in Python
leaving its binaries non-functional for callers. So in this case I see
the responsibility in the court of that package (i.e. the one of
lsb_release), as it happens to be used in another package's postinst. (I
suppose that most binaries shipped by Python modules are not.) So it
could be added to the documentation that it has to call it in this
specific case, too.
Now the question why one would call it is still valid, as it's not
supposed to change during a package's lifetime. At least if it's just to
determine if it's Debian or a derivative, that is. So in general I think
that the way to go is generating a proper snippet for the target
distribution during the package's build process.
Reinhard Tartler wrote:
> > Lets remove all triggers from dpkg then. Updating the Python modules
> > for every new module package is a big waste of time, running it as a
> > trigger results into the described problem in a few rare cases. What
> > do you prefer?
> what about having dkms' postinst executing the trigger to update Python
> modules in this case?
Well, that lsb_release is written in Python is just an implementation
detail, no? So it just should not be the responsibility of the caller.
Kind regards,
Philipp Kern
Reply to: