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.
Attachment:
pgplNM7KvSXRc.pgp
Description: PGP signature