Package: python-support
Version: 0.5.4
Severity: important
Hi,
(Documenting a conversation I had with the python-support maintainer
and another I had with Steinar H. Gunderson on IRC.)
By design, python-support might break some applications. Two examples
lately were the GStreamer 0.10 Python bindings and the GNOME Deskbar
Applet. This is usually because these packages are ./configured with a
default Python path, such as /usr/lib/pythonX.Y/site-packages where the
upstream package expects to find it's *.py and *.pyc files after the
installation (IOW, at runtime), but dh_pysupport moves the *.py to
/usr/share/python-support and byte compiles them into *.pyc files below
/var/lib/python-support.
One workaround is to patch the upstream code to deal with this
situation; this can be complex because upstream might not make any
difference between the path to *.py files and the path to *.pyc files.
The AM_PATH_PYTHON macro understands the difference, but does not
permit changing these.
Another workaround is to use python-central.
Some random thoughts on the issue:
1) I am not too sure that python-support truly needs to adhere to the
FHS since it is only invoked on package installation / upgrades and can
be considered part of "package management".
2) I think *.pyc are arch independent and are supposed to stay that
way, this means that we could have *.pyc under /usr, python-support
could byte-compile unser /usr/share/python-support, hence we could
./configure with this python-path, and we would only have to make sure
that upstream apps do not rely on the system's default. This assumes
1).
3) Not assuming 1), it's possible for python-support to symlink *.py
files to /var/lib/python-support and we could ./configure with this
python-path as in 2).
4) python-support could be changed to allow a second mode of
operations, configurable on a per-package basis, which would symlink
*.py into /usr/lib/pythonX.Y/site-packages and byte-compile there as
well (option a)) or symlink to byte-compiled files (option b)) under
/var/lib/python-support. This compatibility mode could be turned on by
default or only for problematic packages.
Please tag this bug "wontfix" if you do not think it will ever fix. I
intend to use this bug report as a documentation pointer on this
problem, but feel free to include this description in some KNOWNBUGS
file, or as a step to watch carefully when converting packages to
python-support, or when preparing new upstream releases of python
packages.
Bye,
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages python-support depends on:
ii python 2.4.4-1 An interactive high-level object-o
python-support recommends no packages.
-- no debconf information
--
Loïc Minier <[EMAIL PROTECTED]>
