Re: Packaging decompyle - policy question

[Gregor Hoffleit <gregor@hoffleit.de>]

* Ben Burton <benb@acm.org> [011112 19:20]:
> 
> > 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.
> 
> > > 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.

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