Re: Denying #!/usr/bin/env as a valid interpreter

[David Brownlee <abs%netbsd.org@localhost>]

On 17 April 2011 12:59, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> Jörn Clausen <joernc%googlemail.com@localhost> writes:
>
> > On Sat, Apr 16, 2011 at 10:24 PM, Roy Marples <roy%marples.name@localhost> 
> > wrote:
> >> Each time I upgrade pkgsrc, I get annoyed by developer laziness to check
> >> any new files for a valid python interpreter. This is because
> >>
> >> #!/usr/bin/env python
> >>
> >> Is the recommended way of calling python by upstream and
> >> check-interpreter.mk allows it just because /usr/bin/env exists.
> >> Sadly, no binary called python exists on pkgsrc - it's python2.6 for
> >> example.
> >
> > Isn't pkgsrc to blame by not providing a binary called "python"? The
> > /usr/bin/env approach is IMHO a valid method. It has it's drawbacks
> > and in certain situations I would avoid it, in others I would strongly
> > prefer it.
>
> No; the python people are to blame by not having enough compatibility
> among versions - it's not reasonable to install just one python version
> and declare that everything has to build against it.  perl, on
> the other, is mostly ok that way, so one just updates from 5.10 to 5.12,
> and packages that work only on 5.10 but not on 5.12 are viewed as broken.
>
> When installing python, it's not just the interpreter, but lots of
> libraries.  When a package is configured and binds to a path and set of
> libraries, it's wrong to just have that flip to another version.
>
> > How about providing a link "python -> python26" for the default
> > version (as defined by PYTHON_VERSION_DEFAULT)? The same goes for e.g.
> > Java. Why is java not called "java", but e.g. "sun6-java"? It would
> > make things much easier to have a default version available under the
> > name "java". You could still have other versions installed under their
> > original names.
>
> We could accomodate more of this by having a 'python' binary, but it
> means that every package that depends on it would need to be
> rebuilt/replaced when that link changed.

If I download & install a random package from the Internet, having it
use /usr/bin/env is (in general) a good thing, but scripts in pkgsrc
should 'bind' to the right interpreter.

Given I don't think we should be discouraging upstream from using
/usr/bin/env I think the ideal approach would be a well defined
mechanism that could be turned on for any package to replace known
/usr/bin/env usage in the files for that package before install.
Certainly we should not be having patch/ entries for fixing them...