On Thu, Sep 05, 2002 at 08:49:21AM -0500, Dirk Eddelbuettel wrote:
On Thu, Sep 05, 2002 at 07:48:38AM -0500, Dirk Eddelbuettel wrote:
[...]
Remember, /usr/bin/python is a symlink installed by the python package,
and without a dependancy on this package there is no gaurentee that it
will
be there. You can't just use #!/usr/bin/python without depending on the
python package.
Aren't we now fully circular? At first I suggested Depends: python,
and now you recommend the same to me. I guess I need more coffee...
There is a difference between Depends: python, Depends: python (=1.5),
python (2.3), and Depends: python1.5 | python2.1 | python2.2.
The first means depends and works with the default python of _any_ version.
The second means depends and works with the default python for version
1.5 to 2.2. The last means depends and works with pythonX.Y where X.Y is
1.5, 2.1, or 2.2. There are subtle differences between these.
The first makes the rediculous assumption that your package will work with
python 2.3 and beyond, which is why it is a bad idea.
The last does not assume that /usr/bin/python exists, just that
/usr/bin/python1.5 or /usr/bin/python2.1 or /usr/bin/python2.2 does.
The second ensures that /usr/bin/python exists, and points to a version of
python between 1.5 and 2.2 inclusive.
And what about the #!/usr/bin/env trick? Can't that be used to call
whatever suitable python interpreter is found in the $PATH?
This won't help. #!/usr/bin/env python will find ~/bin/python,
/usr/local/bin/python, /usr/bin/python, /bin/python in that order assuming a
typical PATH. Without a dependancy on some version of python there is no
gaurentee that any python executable will exist. It will not find
/usr/bin/python1.5 or /usr/bin/python2.1 or /usr/bin/python2.2, which is
what is installed by the pythonX.Y packages.
I'm pretty sure python silently doesn't save *.pyc files if it can't,
making
them be re-compiled every import. It also re-compiles them if the
*.pyc's
are from a different version of python. This means worst case, python
silently checks existing *.pyc's, recompiles them, then throws them
away for
every run.
It is somewhat of a non-issue by design as wajig is written to be a
higher-level wrapper around tasks requiring root. But wajig is only ever
called as a normal user, and if and when su powers are needed, sudo is
invoked /from inside the python script/ so that no python code should
ever run as root.
which means imported *.py files get re-compiled every time, and the *.pyc
files don't get saved. Unless root does accidently run them once... then
they get created and stay there forever... even after the wajig package is
dpkg --purged.
The proper way of handling this is for the postinst scripts to compile the
*.pyc modules, and the postinst script to remove them. The really
complicated
stuff starts to happen when these script+module packages support multiple
versions of python... If you need more info on this just ask.
I sort-of-know as I once went that route, but it turned out to create
only headaches.
I still suggest you compile and remove the *.pyc's in the post(inst|rem)
scripts. At the very least remove them in the postinst to ensure they are
cleaned up when the package is de-installed.
At some stage in the future I suspect the python package will
dpgk-reconfigure all packages depending on python in it's postinst,
ensuring the *.pyc's are re-compiled when the version of python is
incremented.
--
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--
