On 2011/10/12 03:12, Vadim Zhukov wrote:
I don't like this, ports should use the mechanisms provided in the
infrastructure so that they use the expected version of the interpreter.
If people want to do this for their own programs they can just follow
the advice to create a symlink to their
2011/10/12 Stuart Henderson s...@spacehopper.org:
On 2011/10/12 03:12, Vadim Zhukov wrote:
I don't like this, ports should use the mechanisms provided in the
infrastructure so that they use the expected version of the interpreter.
If people want to do this for their own programs they can
On 2011-10-10, Vadim Zhukov persg...@gmail.com wrote:
Hello all.
While working on Qt/KDE bindings (some KDE apps are build upon them, so I
could not cheat and forget them, leaving porting for someone else :) ),
I've seen many sample scripts that has #!/usr/bin/env some-interpreter
2011/10/12 Stuart Henderson s...@spacehopper.org:
On 2011-10-10, Vadim Zhukov persg...@gmail.com wrote:
Hello all.
While working on Qt/KDE bindings (some KDE apps are build upon them, so I
could not cheat and forget them, leaving porting for someone else :) ),
I've seen many sample scripts
On Wednesday 12 October 2011 02:12:19 Vadim Zhukov wrote:
Maybe I wasn't clear: I propose single python-run package, which
depends on default Python version in ports, and sets up symlink to it
as /usr/local/bin/python.
Packages with only RUN_DEPENDS are not allowed in ports. Just setting up a
Hello all.
While working on Qt/KDE bindings (some KDE apps are build upon them, so I
could not cheat and forget them, leaving porting for someone else :) ),
I've seen many sample scripts that has #!/usr/bin/env some-interpreter
shebangs. They are easily updated via MODXYZ_ADJ_FILES, but do we
