Packaging decompyle - policy question
Ben Burton
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
be...@acm.org | b...@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger b...@debian.org
You can only be you. A lot of times it's never enough for people.
- Tori Amos
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Burton , by way of Ben Burton <benb@acm.org>
> according variant (detection of the .pyc format should be pretty easy,
> it's just a magic number, cf. /usr/share/misc/magic).
Hm, I'll try and find some documentation on how to extract the version
information.
> > 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.
>
> Umm, are you talking about a *binary* or an *script* ? If binaries, how
> big are they ?
Oops, I mean scripts. Very small.
> Would it really be an issue to include three of them in a
> single package ?
No, my problem was with placing them in *separate* packages (decompyleX.Y),
each containing about ten lines of material plus a copyright and changes
file. The problem being package bloat.
Ben.
--
Ben Burton
be...@acm.org | b...@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger b...@debian.org
Every Friday night I have a margarita with a Christian God. I'll
share the observations of my week, and ask for answers and try to keep
an open mind. Then we both move on.
- Tori Amos, Philadelphia Inquirer, May 3, 1998
Gregor Hoffleit
>
> > c) A wrapper that auto-detects the format of the .pyc file and calls the
> > according variant (detection of the .pyc format should be pretty easy,
> > it's just a magic number, cf. /usr/share/misc/magic).
>
> Hm, I'll try and find some documentation on how to extract the version
> information.
>
> > > 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.
> >
> > big are they ?
>
> Oops, I mean scripts. Very small.
>
> > Would it really be an issue to include three of them in a
> > single package ?
>
> No, my problem was with placing them in *separate* packages (decompyleX.Y),
> each containing about ten lines of material plus a copyright and changes
> file. The problem being package bloat.
Have a look at Python/import.c in the Python source tree. The algorithm
for computing the magic is pretty simple (and will start to fail for the
first version in 2002 ;-):
/* Magic word to reject .pyc files generated by other Python versions */
/* Change for each incompatible change */
/* The value of CR and LF is incorporated so if you ever read or write
a .pyc file in text mode the magic number will be wrong; also, the
Apple MPW compiler swaps their values, botching string constants */
/* XXX Perhaps the magic number should be frozen and a version field
added to the .pyc file header? */
/* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */
#define MAGIC (60717 | ((long)'\r'<<16) | ((long)'\n'<<24))
Also, here's a snippet from my /etc/magic file:
0 lelong 0x0a0d4e99 Python bytecode, magic 1997-01-21 (>=1.5.2)
0 lelong 0x0a0dc687 Python bytecode, magic 2000-08-23 (>=2.0.1)
0 lelong 0x0a0deb2a Python bytecode, magic 2001-02-02 (>=2.1.1a1)
0 lelong 0x0a0ded2d Python bytecode, magic 2001-07-17 (>=2.2a2)
(I.e., take the first four bytes of the pyc file and read them as 'long'
in little endian format.) AFAICS, this should suffice for all versions
we have in the distribution.
Gregor
Ben Burton
> > Hi. So I'm packaging decompyle which decompiles a .pyc bytecode file and
> > converts it back to python source.
>
> packaging this for debian, just wondering when I would need it.
I've already used it once, when I inadvertently deleted a .py file and after
searching the web for a decompiler managed to retrieve an almost perfect copy
of the source by running decompyle on the .pyc file.
Ben.
--
Ben Burton
be...@acm.org | b...@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger b...@debian.org
Stop worrying - nobody gets out of this world alive.
- Clive James
dman
| On Mon, 2001-11-12 at 18:22, Ben Burton wrote:
| >
| > Hi. So I'm packaging decompyle which decompiles a .pyc bytecode file and
| > converts it back to python source.
|
| packaging this for debian, just wondering when I would need it.
If you lost the .py file for some reason, but still had the .pyc file.
-D