Re: Help needed with #159208
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: