Packaging decompyle - policy question

[Ben Burton <benb@acm.org>]

Hi.  So I'm packaging decompyle which decompiles a .pyc bytecode file and 
converts it back to python source.

Thing is, decompyle needs to be run with the same version of python that was 
used to create the bytecode.

So the question arises as to what should go in /usr/bin.  Options I see are:

a) A wrapper script /usr/bin/decompyle which takes an addition argument 
specifying the python version to run and calls the real decompyle with that 
version of python (and defaulting to the default version of python);

b) A series of binaries /usr/bin/decompyle1.5, /usr/bin/decompyle2.1, etc 
with the additional /usr/bin/decompyle that uses the default debian version 
of python.

I'm leaning towards option (b), but this then leads to the issue of how the 
binaries should be packaged.  Should there be a single package decompyle 
which provides all of these binaries?  Or should there be packages 
decompyle1.5, decompyle2.1, etc.?

If there are several packages then each package will literally contain a 
single script and a symlink to a man page and would depend on 
decompyle-common which contains the actual decompyle itself.  This seems a 
bit of an overkill.  But on the other hand I don't want to provide binaries 
that people can't run (if the appropriate python version is not installed) 
and I don't want decompyle to depend on *every* version of python in debian.

Thoughts?

Ben.

-- 

Ben Burton
benb@acm.org  |  bab@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger bab@debian.org

You can only be you. A lot of times it's never enough for people.
	- Tori Amos