> 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.
> 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.
- 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.
* 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.
* 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.
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?
