Packaging with the new Python policy: A package developers view | ||
---|---|---|
Prev |
Some packages may need more changes during an update of the default python version (i.e. setting an alternative, restarting a daemon). These packages can either provide their own upgrade scripts (run during the update of the default python version), or continue to use the old dependency on exactly the current python version to ensure that the package is updated together with the default python version and use the normal installation/removal scripts. The utility packages python-central and python-support provide upgrade scripts in order to facilitate their byte compilation work. [1]
When the default python version is changed, the maintainer scripts of the python package arrange for the execution of package provided scripts. These scripts are placed in /usr/share/python/runtime.d/, must have an .rtupdate extension and must be executable. These scripts must be idempotent; since any script may be called multiple times during a Python version change with the same arguments.
These scripts must be rigorously tested, since any failure in the scripts would make the new Python package changing the default version to fail to install.
Each script is called with one of pre-rtupdate, rtupdate or post-rtupdate as the first parameter. If nothing needs to be done the invocation should be ignored by the script.
in the pre-installation phase of the python package, the package supplied scripts are called with the parameter: pre-rtupdate <old runtime> <new runtime>
A failure in any script results in the failure of the pre-installation script of the python package.
Whether or not all scripts are run, or the process aborts at the first failure, is still under flux |
During the post installation phase of the python package, the package supplied scripts are called with the parameter: rtupdate <old runtime> <new runtime>
This is the hook used by python-central and python-support to byte compile pure Python modules; and packages handling their own byte compilation should use this hook as well. However, at this phase of the installation process, the state of the default Python package is in flux, so complex operations involving the default version are best avoided.
A failure in any script results in the failure of the post-installation script of the python package, and may leave other Python packages in an non-working state (since the modules may not be compiled with the default version). A failure in this script is also a critical bug.
During the post installation phase of the python package, the package supplied scripts are called with the parameter: post-rtupdate <old runtime> <new runtime>
A failure in any script results in the failure of the post-installation script of the python package. Such a failure only affects the package which owns the script, and does not impact the other related packages, so a problem in the post-rtupdate script is less critical, and would only have the severity grave or serious.
[1] | This section is based on basic rtupdate documentation |