On 28/05/10 21:09, Nezmer wrote:
On Fri, May 28, 2010 at 11:17:49AM +0200, Xavier Chantry wrote:
On Fri, May 28, 2010 at 10:57 AM, Pierre Schmitz<[email protected]> wrote:
I would say make sure that core packages are fine with /bin/sh being dash
and then move it to testing. This should speed up things. For the install
scripts: why can't pacman just call /bin/bash? I mean makpekg and the
PKGBUILDS need bash anyway.
I think that the two pending patches from Jonathan Conder on my branch
http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
would make this cleaner and easier to do.
1) switch from popen to execl : popen implicitely calls /bin/sh, so
when we had /bin/sh=dash and wants bash, it would call /bin/dash then
/bin/bash. But execl gives us more control.
2) ldconfig is now called directly so if we do the change /bin/sh ->
/bin/bash, it only affects scriptlet executions.
But I am pretty sure we talked about this before, maybe there was a
bug report, and some people suggested to make the shell path
configurable.
Thinking about it now, I would be fine with just calling /bin/bash
directly. If we consider pacman project as a whole, it's pretty much
tied to bash anyway.
+1 from someone who is using pacman in a FreeBSD environment. Where
"/bin/sh" is linked to neither bash nor dash.
bash is used in both makepkg and repo-add. It's not a platform-dependent
terrible dependency. And for recovery purposes, It can optionally be built
statically. The static option is actually supported as a configure flag.
People who use pacman do not necessarily use makepkg or repo-add so
using that as a basis for hard coding /bin/bash is wrong.
Dan and I have discussed allowing a #! at the top of install scripts. I
think he had some very draft code that even allowed python scriptlets!
Allan
