Re: Python upgrade path (draft/proposal)
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 <lawrencc@debian.org> - http://www.lordsutch.com/chris/w
Reply to: