Re: version independent pythin packages: ?
On Thu, 2003-08-07 at 03:22, Matthias Urlichs wrote:
> Hi,
>
> Python policy states:
>
> 2. A single package for all versions (NOT YET SUPPORTED!)
>
> You have a version independent Python module. Create a single
> package `python-<foo>' that has a dependency
>
> Depends: python
>
> It should install modules somewhere inside
> `/usr/lib/python/site-packages/' and use `#!/usr/bin/python' for
> programs. The `postinst' script should create symlinks in all
> `/usr/lib/pythonX.Y/site-packages/' directories that point to
> its `/usr/lib/python/site-packages/' files and compile them.
>
> This may be a dumb question, but why not use /usr/lib/site-python?
> Since that's in the PYTHONPATH for all Python versions Debian ships with,
> there should be no requirement to do any post-installation of symlinks.
>
> Some .pyc files might possibly be out-of-date, but for reasonably-small
> packages that won't be much of a problem, IMHO.
This is an interesting idea... Python will re-generate pyc files if they
are needed, and save them if it can.
What this means is the pyc files will be "updated" every time they are
used by a different version of python when the user has write access. If
the user doesn't have write access, then everything will still work, but
python will re-compile them every time a different version of python is
used.
Ideally the pyc files in /usr/lib/site-python should be compiled for the
default version of Python, and write access to this directory should be
limited to minimise overwriting them.
This means users without write access to /usr/lib/site-python will use
the pyc's when running the default python, and will re-compile them
every time they use a non-default python, but everything will still
work.
The only problem is when someone with write access to
/usr/lib/site-python uses a non-default python... the pyc's will be
"updated" for the non-default python.
After testing, it seems that there is no way to prevent root from
updating the pyc's when using a non-default python. However, even if
this does occur, everything will still work, it will just be slightly
less optimal when using the default python. The only solution is "root
should never use the non-default python when importing modules from
/usr/lib/site-python"... which may or may not be OK.
Given the complexity of the alternatives, this is a simple solution that
fixes the problem with only minor issues. I'd be tempted to make this
the solution and put it into the Python policy.
Anyone else agree?
Other things to think about;
Python applications using the default Python with their own modules not
in /usr/lib/site-python... not an issue?
Making sure all the pyc's are re-compiled when the default python is
updated.
A brute force approach is to have the python packages post-inst run
"dpkg-reconfigure" over every package that depends on "python", and
require that packages recompile their pyc files on a "dpkg-reconfigure".
This has the advantage of "notifying" all these packages when the
default python has changed so they can do other stuff if they need to.
--
Donovan Baarda <abo@minkirri.apana.org.au>
Reply to: