On Fri, 2009-07-17 at 01:54 -0700, Toshio Kuratomi wrote: I wrote that page. I hope the information in it is accurate and that the policy it expresses is worthwhile. However I don't have the time to own the feature and push it to completion [1]. If someone else wants to own it that would be great. (perhaps I should have put it in the drafts namespace?) Dave [1] doomed with $DAY_JOB stuff at the moment

On 07/19/2009 05:11 AM, Jonathan Underwood wrote: It's not easy to fix 100% correctly, though. #!/usr/bin/myinterp Argument Rpm can put a dependency on the file /usr/bin/myinterp. Pretty easy. #!/usr/bin/env myinterp Rpm can put a dependency on /usr/bin/env. Then it has to have a special case for /usr/bin/env that says look at the next argument and treat that as a dependency also. Then it has to resolve what myinterp is. The big thing there is that there's no guarantee that the building host has myinterp installed. Many scripting languages are fine if you use install (or cp) to install the script to the proper directory and don't need to have the interpreter installed until runtime. -Toshio

On 07/22/2009 08:54 AM, Braden McDaniel wrote: Well, the primary reason for using #!/usr/bin/env is script-portability to support cases, in which using a hard-coded interpreter is not feasible. Such cases typically are a) there is no "standardized location" for an interpreter. e.g. though presuming presence of /bin/bash is pretty safe on Linuxes, there is no "standardized location" for bash on "non" Linuxes. b) /usr/bin/env is handy for cases in which not using the "standard interpreter" is not desired. Examples would be - testing/development purposes (e.g. when developing on such an interpreter, e.g. a new bash) - testsuites to be run inside of a package. They typically want to use the newly built interpreter and do not the system-wide version. As b) is suiteable for distribution and development purposes, it is a pretty compelling approach to keep a package simple on the developer's part. IMO, /usr/bin/env is not necessarily harmful. It may cause undesired side-effects if being carelessly used. That said, my attitude on this is ambivalent and I am not convinced, banning /usr/bin/env is a good idea. One one hand, banning /usr/bin/env restricts the distro and helps assuring consistency withing the distro, on the other hand, it restricts usability of distro (for development purposes) and forces either developers or packagers to _generating_ scripts. Ralf

On 07/21/2009 11:54 PM, Braden McDaniel wrote: I see this falling into two cases: 1) /usr/bin/env was cut and pasted into the script by upstream without understanding what the tradeoffs are with /usr/bin/INTERPRETER. In these cases, upstream may be willing to accept a patch to use /usr/bin/INTERPRETER when we explain that some system administrators install multiple versions of the INTERPRETER on a system in different directories and rely on their path to sort things out for their site-local scripts. 2) /usr/bin/env is being used upstream purposefully. This would be when the upstream is trying to work in situations where INTERPRETER isn't installed in /usr/bin/INTERPRETER and they are not concerned by multiple versions of the INTERPRETER conflicting. This is a case where I think it is appropriate for Fedora to carry a Fedora-specific patch. Reasoning: Upstream and Fedora have different aims in this case. Upstream is trying to ensure that their script runs on as many different operating systems as possible. Fedora is trying to ensure that the script runs on Fedora systems even if local admins have installed extra interpreter versins. /usr/bin/env supports upstream's case but breaks the Fedora case. So this is something that we should be changing locally as it makes the scripts more robust on Fedora and the change is reasonably simple - change the first line of executable files. A solution that would meet both upstream and Fedora's usage would be to change the build scripts of the packages to substitute the interpreter lines in at build time. -Toshio

On 07/23/2009 10:58 PM, Braden McDaniel wrote: The toolchain is only a minor point. The major point is that it causes breakage for some end users. -Toshio