About byte compilation and cleanup when packages share a directory
Hello all, A couple of days ago I upgraded some of my python packages to follow the new policy and I've found that three of them are buggy, but I want some advice on how to proceed. The packages in question are ``childsplay``, ``childsplay-plugins`` and ``childsplay-plugins-lfc``. The fist thing I've detected is that I'm installing everything on ``/usr/share/childsplay``, but probably the right place is ``/usr/share/games/childsplay``. That is easy to fix, but before changing that I want to fix the other annoying bug, only present on ``childsplay-plugins`` and ``childsplay-plugins-lfc``. The problem comes from the use of dh_pysupport, on both packages I'm including a call like: dh_pysupport /usr/share/childsplay on debian/rules, this call can be replaced by one that only compiles the files inside the ``lib`` subdirectory, as the plugins are installed there. The dh_pysupport call will be now: dh_pysupport /usr/share/childsplay/lib or: dh_pysupport /usr/share/games/childsplay/lib if I move the private modules directory. The bug I've detected is related to the way the byte compiled files are handled; when ``childsplay`` is installed all the ``.py`` files under the ``childsplay`` modules dir are generated (including the default plugins included on ``lib``) and later, when ``childsplay-plugins`` or ``childsplay-plugins-lfc`` are installed, the same files plus the new ones are recompiled again (at least the ones inside of ``lib``, if I fix the ``dh_pysupport`` call). That is no real problem, as the double recompilation has no real effect on the system and the result is the same, the problem comes when you remove one of the plugin packages, for example the ``childsplay-plugins-lfc`` one, on that case ``dh_pysupport`` removes all the ``.pyc`` files on the ``lib`` subdirectory, that is, it removes all the byte-compiled files from ``childsplay`` and ``childsplay-plugins`` that are there. Now my questions: - How should I handle that case? - Is anybody else using a plugin system that leaves ``.py`` files inside a module directory already handled by python-support? - Should I file a bug report against python-support to implement a way to handle individual python files instead of full directories? - Does python-central solve this kind of problem? Thanks in advance for your comments. Geetings, Sergio. -- Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/ Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69 signature.asc Description: Digital signature
Re: New python maintenance team
El Thu, Apr 06, 2006 at 09:58:02AM +0200, Raphael Hertzog va escriure: Who would be interested to help ? My time is limited but I'll be interested in joining the team. -- Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/ Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69 signature.asc Description: Digital signature
Re: Python only packages and the new Python policy
El Tue, Jul 05, 2005 at 12:14:00AM -0700, Donovan Baarda va escriure: My proposal for those cases is simple: why don't we remove /usr/lib/site-python/ from the python path and link the contents of that directory on /usr/lib/pythonX.Y/site-python/ on the postinstall of pure python packages that install their code on /usr/lib/site-python/? With this system, when a new pythonX.Y package enters the archive it can build his own linked version of /usr/lib/site-python/, leaving the compiled files on /usr/lib/pythonX.Y/site-python/. The main advantage is that the package is available to all installed python versions and supports zero work transitions. [...] Of course all that should be elaborated and formalized a little bit to enter into the Policy document, but I would like to know what do others thing about it and know what other solutions or changes have been proposed for the next version of the policy, if any. This is exactly like the proposal already described but not yet supported in the current Python Policy. The only difference is it suggests using /usr/lib/python/site-packages instead of /usr/lib/site-python. Right, I should have re-read the policy before sending the e-mail. The only reason this is not yet supported is no-one has yet made it work. The closest thing is the work done on python-central... OK, then I'll take a look and see if I can write a script to support it, it seems quite simple but maybe I'm missing something... -- Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/ Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69 signature.asc Description: Digital signature
Python only packages and the new Python policy
Hello all, I was reading the last messages to the list and I've noticed that all python packages I have are pure python and I that I could install them for all python versions (at least for python =2.3), but if I install the code on /usr/lib/site-python/ the code will only work with the current python version and the multiple package solution looks an overkill, as some people said. My proposal for those cases is simple: why don't we remove /usr/lib/site-python/ from the python path and link the contents of that directory on /usr/lib/pythonX.Y/site-python/ on the postinstall of pure python packages that install their code on /usr/lib/site-python/? With this system, when a new pythonX.Y package enters the archive it can build his own linked version of /usr/lib/site-python/, leaving the compiled files on /usr/lib/pythonX.Y/site-python/. The main advantage is that the package is available to all installed python versions and supports zero work transitions. The only problem with this approach is what to do with pure python packages known to work only with a range of python interpreters, but we can solve that including a file with the package that declares the range of valid interpreters. The good thing about this latter proposal is that is that the system can be used also for non pure python packages, putting python code on a package that declares no supported version (that is, declares a null range of interpreters) and puts the version dependent code on another package that adds the given python version to the list of valid interpreters, generates the links and recompiles the python files. Of course all that should be elaborated and formalized a little bit to enter into the Policy document, but I would like to know what do others thing about it and know what other solutions or changes have been proposed for the next version of the policy, if any. Greetings, Sergio. -- Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/ Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69 signature.asc Description: Digital signature
Python postinstall scripts and compileall.py
Hello all,
Today I was looking at a bug report and while reviewing it I noticed
that my postinstall script was wrong.
The package installs 3 files in '/usr/lib/python$PV/site-packages',
but after installation I wasn't compiling them.
I looked at other python packages and I noticed that when the package
puts files on that directory the 'postinstall' scripts I've looked at
use the 'compileall.py' script over the
'/usr/lib/python$PV/site-packages' directory.
While that works O.K., it compiles everything under this directory and
recurses until a depth of 10 subdirectories by default.
In general it compiles nothing but the package files (each package
should have compiled its sources), but I feel that this is not the
right thing to do, IMHO every package should only take care of it's
own files and don't touch others (unless it's really needed).
I'm writting to the list to know what do you think about it.
By the way, in my package I've modified the postinstall to compile
only my files, the script is:
--*-- BEG: postinst --*--
#! /bin/sh -e
#
# postinst script for Debian python packages.
# Written 1998 by Gregor Hoffleit [EMAIL PROTECTED].
# Modified 2001 by Matthias Klose [EMAIL PROTECTED]
# Modified 2003 by Sergio Talens-Oliag [EMAIL PROTECTED] for the
# python-htmltmpl package (only compile our .py files).
PACKAGE=`basename $0 .postinst`
PV=`dpkg --listfiles $PACKAGE | sed -n -e '/^\/usr\/lib\/python.*\//{
s,/usr/lib/python\([0-9][0-9.]*\)/.*,\1,p
q
}'`
PYTHON=python$PV
FILELIST=`dpkg --listfiles $PACKAGE | grep
^/usr/lib/python.*/site-packages/.*.py$`
case $1 in
configure|abort-upgrade|abort-remove|abort-deconfigure)
for i in $FILELIST; do
/usr/bin/$PYTHON -O -c import py_compile; py_compile.compile('$i')
/usr/bin/$PYTHON -c import py_compile; py_compile.compile('$i')
done
;;
*)
echo postinst called with unknown argument \`$1' 2
exit 1
;;
esac
#DEBHELPER#
exit 0
--*-- END: postinst --*--
--
Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
pgpwbkGVzYf9A.pgp
Description: PGP signature
