Re: dkms needs a pre-depends entry (Policy 3.5)
Steve Langasek writes (Re: dkms needs a pre-depends entry (Policy 3.5)): 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. Exactly. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19526.56876.656995.37...@chiark.greenend.org.uk
Re: dkms needs a pre-depends entry (Policy 3.5)
Russ Allbery writes (Re: dkms needs a pre-depends entry (Policy 3.5)): This implies to me that the following information in the python-support documentation is partially incorrect: Yes, I think so. 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? I think so, although the manpage for update-python-modules I have here doesn't document the -p option so I'm going partially on guesswork. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19526.57303.661678.381...@chiark.greenend.org.uk
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 be...@bzed.de writes: It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). That's not correct. You can assume that your dependencies are configured before you're configured unless there are circular dependencies involved. Right. The difficulty here is that if you both depend on a package and trigger it in your postinst, when your postinst starts the package is configured, but when you trigger it, it stops being configured but your postinst is still running. You have to deal with that case yourself somehow. The package you're triggering and depending on should provide a synchronous way for you to force your addons to that package to be ready for use by you right now, as well as just the trigger (which is a way to make sure they'll be ready for other people). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19526.57519.985127.605...@chiark.greenend.org.uk
Re: dkms needs a pre-depends entry (Policy 3.5)
On 07/18/2010 02:35 AM, Ben Hutchings wrote: On Sat, 2010-07-17 at 17:03 +, Philipp Kern wrote: On 2010-07-17, Ben Hutchings b...@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. 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. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c459834.2060...@bzed.de
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 14:36:04 (CEST), Bernd Zeimetz wrote: On 07/18/2010 02:35 AM, Ben Hutchings wrote: On Sat, 2010-07-17 at 17:03 +, Philipp Kern wrote: On 2010-07-17, Ben Hutchings b...@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. 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? Also adding update-python-modules -p to a postinst script does not hurt, even when dependencies change. I guess this is exactly what the trigger does, right? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aapmfces@faui44a.informatik.uni-erlangen.de
Re: dkms needs a pre-depends entry (Policy 3.5)
Bernd Zeimetz be...@bzed.de writes: Lets remove all triggers from dpkg then. For things that have to run to make the package usable, yes. 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? I prefer packages to work after they've been configured. Otherwise, Depends doesn't do what it's supposed to do. 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. Also adding update-python-modules -p to a postinst script does not hurt, even when dependencies change. This is true, but one shouldn't have to configure another package if one already depended on it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aapmgksr@windlord.stanford.edu
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 be...@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 unpackednever maybeNopostinst configure c.-failed never maybeNopostinst configure (when requested) t.-awaited yesalways Nopostinst triggered + fix awaited pkg(s) t.-awaited no always Nofix awaited package(s) t.-pending always neverYes postinst triggered installed never neverYes 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19525.59242.441242.945...@chiark.greenend.org.uk
Re: dkms needs a pre-depends entry (Policy 3.5)
Ian Jackson ijack...@chiark.greenend.org.uk writes: 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. The problem here is that the package that's being triggered isn't either of the packages that are involved, I believe. The package being triggered is python-support, which is a dependency of lsb-release, but the package failing is dkms, which has no dependency on python-support, only on lsb-release. What's happening, as I understand it, is: * nvidia-kernel-dkms is requested to be installed. * dkms is added due to dependency. * lsb-release is added due to dkms dependency. * python-support is already installed. * lsb-release, dkms, and nvidia-kernel-dkms are unpacked. * Pending trigger added for python-support. * lsb-release is configured. == does this force python-support's trigger to run? * dkms is configured. * nvidia-kernel-dkms is configured and attempts to build the module. Now, this was definitely broken before because dkms only recommended lsb-release and didn't depend on it. But does this work properly if there's an actual dependency? Right now, it's pre-depending, it looks like, which should be too strong and not required. [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. So, nvidia-kernel-dkms's postinst shouldn't run until all of its dependencies are configured, so I think my question is: does dpkg wait to call the postinst of nvidia-kernel-dkms until after python-support's trigger runs, when python-support is a dependency of lsb-release and lsb-release is in turn a dependency of dkms, which is a dependency of nvidia-kernel-dkms? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aapmf02v@windlord.stanford.edu
Re: dkms needs a pre-depends entry (Policy 3.5)
On 2010-07-20, Bernd Zeimetz be...@bzed.de wrote: On 07/18/2010 02:35 AM, Ben Hutchings wrote: On Sat, 2010-07-17 at 17:03 +, Philipp Kern wrote: On 2010-07-17, Ben Hutchings b...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni4bt29.vbi.tr...@kelgar.0x539.de
Re: dkms needs a pre-depends entry (Policy 3.5)
On 07/20/2010 09:08 PM, Philipp Kern wrote: 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. It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). So if you depend on a properly install *and* configured lsb_release, either add a Pre-Depends *or* chose a different way to ensure it is configured properly. And this is an easy one actually as all you need to do is to run update-python-modules -p. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c45fc95.50...@bzed.de
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 21:44:21 +0200, Bernd Zeimetz wrote: On 07/20/2010 09:08 PM, Philipp Kern wrote: 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. It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). Where in 3.5 do you read that? Cheers, Julien signature.asc Description: Digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
Bernd Zeimetz be...@bzed.de writes: It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). That's not correct. You can assume that your dependencies are configured before you're configured unless there are circular dependencies involved. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739vdgbxj@windlord.stanford.edu
Re: dkms needs a pre-depends entry (Policy 3.5)
On 07/20/2010 09:50 PM, Julien Cristau wrote: On Tue, Jul 20, 2010 at 21:44:21 +0200, Bernd Zeimetz wrote: On 07/20/2010 09:08 PM, Philipp Kern wrote: 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. It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). Where in 3.5 do you read that? Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package. We have exactly this case here. lsb_release needs to be configured first. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c4600af@bzed.de
Re: dkms needs a pre-depends entry (Policy 3.5)
Bernd Zeimetz be...@bzed.de writes: Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package. Installed here means unpacked, not configured. There's a pending Policy bug to clarify that. We have exactly this case here. lsb_release needs to be configured first. No. dkms doesn't need lsb-release to be configured before it can be unpacked. That's not this case. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6d5ex8p@windlord.stanford.edu
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 4:01 PM, Bernd Zeimetz be...@bzed.de wrote: On 07/20/2010 09:50 PM, Julien Cristau wrote: On Tue, Jul 20, 2010 at 21:44:21 +0200, Bernd Zeimetz wrote: On 07/20/2010 09:08 PM, Philipp Kern wrote: 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. It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). Where in 3.5 do you read that? Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package. We have exactly this case here. lsb_release needs to be configured first. 3.5 is an overview. 7.2 has the details: Depends This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilfd44s7gbgrlpgxyrogqv5ixstsfzzwfurn...@mail.gmail.com
Re: dkms needs a pre-depends entry (Policy 3.5)
On 07/20/2010 10:04 PM, Russ Allbery wrote: Bernd Zeimetz be...@bzed.de writes: Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package. Installed here means unpacked, not configured. There's a pending Policy bug to clarify that. Thanks for the clarification, I fall about that one once a year. We have exactly this case here. lsb_release needs to be configured first. No. dkms doesn't need lsb-release to be configured before it can be unpacked. That's not this case. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c460284.4090...@bzed.de
Re: dkms needs a pre-depends entry (Policy 3.5)
Bernd Zeimetz be...@bzed.de writes: On 07/20/2010 10:04 PM, Russ Allbery wrote: Installed here means unpacked, not configured. There's a pending Policy bug to clarify that. Thanks for the clarification, I fall about that one once a year. It's very confusing right now. See the patch I sent this morning to http://bugs.debian.org/504880 that will hopefully clear this up and be more explicit about what package maintainer scripts can assume. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyntewrz@windlord.stanford.edu
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 22:01:51 +0200, Bernd Zeimetz wrote: On 07/20/2010 09:50 PM, Julien Cristau wrote: On Tue, Jul 20, 2010 at 21:44:21 +0200, Bernd Zeimetz wrote: On 07/20/2010 09:08 PM, Philipp Kern wrote: 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. It should as you can't assume that your dependencies are configured when your own package is being configured (Debian Policy 3.5). Where in 3.5 do you read that? Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry ^ This should be read as unpacked, AIUI. for the package. We have exactly this case here. lsb_release needs to be configured first. No we don't. Cheers, Julien signature.asc Description: Digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 12:02:48PM -0700, Russ Allbery wrote: The problem here is that the package that's being triggered isn't either of the packages that are involved, I believe. The package being triggered is python-support, which is a dependency of lsb-release, but the package failing is dkms, which has no dependency on python-support, only on lsb-release. What's happening, as I understand it, is: * nvidia-kernel-dkms is requested to be installed. * dkms is added due to dependency. * lsb-release is added due to dkms dependency. * python-support is already installed. * lsb-release, dkms, and nvidia-kernel-dkms are unpacked. * Pending trigger added for python-support. * lsb-release is configured. == does this force python-support's trigger to run? * dkms is configured. * nvidia-kernel-dkms is configured and attempts to build the module. Now, this was definitely broken before because dkms only recommended lsb-release and didn't depend on it. But does this work properly if there's an actual dependency? Right now, it's pre-depending, it looks like, which should be too strong and not required. So, nvidia-kernel-dkms's postinst shouldn't run until all of its dependencies are configured, so I think my question is: does dpkg wait to call the postinst of nvidia-kernel-dkms until after python-support's trigger runs, when python-support is a dependency of lsb-release and lsb-release is in turn a dependency of dkms, which is a dependency of nvidia-kernel-dkms? 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
Steve Langasek vor...@debian.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: update-python-modules -p 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrspbuts@windlord.stanford.edu
Re: dkms needs a pre-depends entry (Policy 3.5)
On Sat, Jul 17, 2010 at 17:41:26 +0200, Giuseppe Iuculano wrote: Setting up nvidia-kernel-dkms (195.36.24-4) ... Loading new nvidia-195.36.24 DKMS files... Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release First Installation: checking all kernels... Building only for 2.6.32-5-amd64 Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release This looks to me like a missing dependency on lsb-release in nvidia-kernel-dkms, not in dkms. And I don't understand why a Pre-Depends would be necessary anywhere. Care to explain? Cheers, Julien signature.asc Description: Digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
On 07/17/2010 05:49 PM, Julien Cristau wrote: This looks to me like a missing dependency on lsb-release in nvidia-kernel-dkms, not in dkms. And I don't understand why a Pre-Depends would be necessary anywhere. Care to explain? nvidia-kernel-dkms postint runs /usr/lib/dkms/common.postinst (added by dh_dkms) so imho this is not a missing dependency in nvidia-kernel-dkms. Anyway you are right, I was under the impression that lsb-release was used in preinst, and not in postinst. So a Depends entry is sufficient, I will fix that soon. Cheers. Giuseppe. signature.asc Description: OpenPGP digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
On Sat, 2010-07-17 at 16:49 +0100, Julien Cristau wrote: On Sat, Jul 17, 2010 at 17:41:26 +0200, Giuseppe Iuculano wrote: Setting up nvidia-kernel-dkms (195.36.24-4) ... Loading new nvidia-195.36.24 DKMS files... Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release First Installation: checking all kernels... Building only for 2.6.32-5-amd64 Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release ImportError: No module named lsb_release Traceback (most recent call last): File /usr/bin/lsb_release, line 26, in module import lsb_release This looks to me like a missing dependency on lsb-release in nvidia-kernel-dkms, not in dkms. And I don't understand why a Pre-Depends would be necessary anywhere. Care to explain? 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. I also wonder whether a distribution package of dkms really needs to use lsb_release at all. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: dkms needs a pre-depends entry (Policy 3.5)
On 2010-07-17, Ben Hutchings b...@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 Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni43oia.2n9.tr...@kelgar.0x539.de
Re: dkms needs a pre-depends entry (Policy 3.5)
On Sat, 2010-07-17 at 17:03 +, Philipp Kern wrote: On 2010-07-17, Ben Hutchings b...@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). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
