On Oct 18, Matthias Klose wrote:
May I suggest a simpler alternative for (b) (or maybe an alternative c):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
/usr/lib/pythonx.y/site-packages, it won't hurt anything if the
other version is not installed. If the files are identical, they
should only appear in the package once (use hard links or symlinks,
but don't symlink directories because of .py[co]). Depend on
python-base (= 1.5.2-1) and nothing should break. Build-depend on
both python1.5-base and python2.1-base.
Depend on python-base (= 1.5.2-1), python-base ( 2.2), or do you
_know_ the future ;-? You have to make a new upload, but it's an
acknowledgement by the package that he actually tested the package
with the new version.
I typo'ed here. I meant python1.5-base | python2.1-base.
Since the buildds need both versions installed to make
python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
problems.
The only downside is that people with one installed python will get
extra cruft installed, but the use of links should minimize it. I'd
follow this alternative unless the package consists entirely of .so
files and the .so files are *big*.
Is it really simpler?
- from the user's point of view, you have to install packages you
don't want.
Well, you have to install *files* you don't want, but you don't need
all of the pythonX.Y-base packages, just the particular version you
want to use. The point is that the user doesn't have to care which
Python he has installed to figure out which extension to use; it just
works.
- from the package maintainer's point of view,
* you have to make new uploads every time a new python is installed/
adjust your packaging rules.
Well, you have to do that anyway, regardless.
* you have to make sure your symlink system works for every single
package. I would prefer a system, availabe in python-base, but
then each package would have to pre-depend on python-base.
I haven't tested it with a package that installs .py files. I may try
to do it with reportbug this weekend and share my results.
* it's limited to arch independent packages. python1.5 and python2.1
have different ABIs. I didn't look at 2.1 and 2.2 compatibility.
No, arch dependent packages can have separate so files for each major
version of Python; see python-pqueue 0.2-3 for an example. It's
actually easier with arch dependent packages because you're not
duplicating files.
i.e. there is:
/usr/lib/python1.5/site-packages/pqueuemodule.so
/usr/lib/python2.1/site-packages/pqueuemodule.so
two modules, compiled against the appropriate pythonX.Y-dev packages.
The beauty of it is that if you don't have one version installed, it
doesn't matter, except for the disk space you're using. (Hence why I
said not to use it for big .so files, where big is probably = 100k or
so.)
Anthony Towns describe a register/unregister system in
http://lists.debian.org/debian-python/2001/debian-python-200110/msg00066.html
Do you want to give it a try?
That much overhead may not be necessary; really, all you need to do in
your postinst is (in Python... adjust to sh as you see fit):
for version in glob.glob('/usr/bin/python?.?'):
sys.system(version+' compileall.py
/usr/lib/'+version+'/site-packages/my-package')
sys.system(version+' -O compileall.py
/usr/lib/'+version+'/site-packages/my-package')
Seems short, simple, and to the point. The only downside is you won't
automatically get new .pyc and .pyo files every time you install a new
major version (in which case it might be nicer to go with something
like a register/unregister system... YMMV).
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/w
