Arch Linux

This is not a pacman bug. Pacman uses /bin/sh and that is entirely intended.

It is also not an Arch bug. Arch supports /bin/sh being bash and so can use bashisms for its install scripts. However, if there are bashisms in the Arch .install scripts and these can be made usable by other shells, I think that such request would be implemented.

I'm surprised your system works at all with an alternate shell at /bin/sh, I tried this many moons ago and it failed miserably.

Bashisms should be removed if possible from install scripts as Allan mentioned- I would support having a different default /bin/sh but there was a lot of (perceived) resistance last time I tried that. If Ubuntu can do it though...

Also see http://www.archlinux.org/pipermail/pacman-dev/2009-July/009039.html (the 6 posts there) and  FS#13803 

Well, this could be improved with an added setting in pacman.conf, for those (like me) who prefer to use dash as the system shell, so people not wondering to use an alternate shell does not have to bother with it, nor package maintainers. Only a (little?) dev on pacman.

For people who tried using dash a few months ago, I had the same problem, but now this seems ok (at least all init scripts work out of the box). The only remaining problem is with packages.

The only problem you stated is : a non portable shift instruction
As I already said in the other two links above, with the current pacman code, the 3 lines at the end of most scriptlets containing the shift can be simply removed.
That means you can fix ALL scriptlets with one simple sed line.

Now if you find other compatibility problems, just open a specific bug report for each problematic package (ideally with a patch)

A setting in pacman.conf is stupid, what would it do? The only thing which makes sense would be to have pacman call explicitely /bin/bash, as you already said. The thread on the ML contains a patch which does that, and also suggestions for improving that patch.
But if we need to do that just because of a shift command which is not even used, it's a pity...

Well, I were not figuring to check and modify all packages which could contain such statments - I should do it for all packages, not only installed one - maybe an announce on the ML for package maintainers could please them to check there packages ?

I understand that adding a configuration for one invalid command (used or not) is not really interesting :) However, it's more a way to be more souple, because:
* people wanting an alternate default shell do not have to worry about their shell's compatibility (as long as it's Bourne compatible)
* package maintainers do not have to worry about the default system shell, as long as pacman dicts the shell to use (what would be distro specific) so bash enforcement could be done, while the restriction does not apply to the default shell.
It's not so stupid, it's just another way to see how pacman could apply to any distro, or even to Arch when bash won't be the 'preferred' shell.

I won't check and modify the whole repository database, making a patch for each. The better I can do is to make this check and the patches for packages I use. But each time I'll install a faulty package, I'll have to make another patch, and then reinstall the software (hoping the patch will be applied before my next update). That's not IMHO a good way, but laking other solution, I'll take it.

Wait, before opening specific bug, we first need to do the easy fixes on all scriptlets.
 FS#13803  actually has patches for core and extra, but it is probably outdated now.
It would be good to know if this was made automatically, or if it also needed some manual fixes (I didn't even look at the patches yet).

And maybe we can do a check by just sourcing all scriptlets in ABS with dash and look for errors.

In any cases, we need to get at least on Arch dev involved..
But I think the discussion can continue on  FS#13803  and this one can be closed.

Ok, I already made a task closure request.

I'm not a massive user of Arch - and so do not use ABS (yet). I'll follow the discussion on  FS#13803  though.

As suggested, a pacman option pointing to which shell to use for scriptlets would be a neat solution. One could even set it to /usr/bin/python for some distro using python based install scriptlets