Re: Packaging decompyle - policy question
> 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.
Ben.
--
Ben Burton
benb@acm.org | bab@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger bab@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
Reply to: