I think /bin/sh being bash kinda falls under the common sense category. I'd be fine with documenting that. I could also see updating the recommended scriptlet invocation but that would be a separate cleanup and I wouldn't tag it as something that packagers must change in their packages.

I would be against making macros for all of these scriptlets -- I've come to realize that having the code spelled out makes things easier for sysadmins to transition into packagers. However, if Fedora's rpm gains the marking-packages-by-type-and-then-execute-certain-actions-based-on-type ability I'd be willing to take advantage of it even though it has the same negative result. The semantic marking seems like a large enough offsetting factor to me.

Won't be at the meeting today, so....

/bin/sh is bash in Fedora. The packaging guidelines are for Fedora. If someone wants to go replacing the system shell, they aren't running Fedora and they'll almost certainly run into all kinds of issues we shouldn't really care about.

I'm for anything that makes the spec files simpler. If that means using bash extensions in scriptlets, I'm all for it. I'm certainly happier if that rpm collections thing does come into being because it lets us avoid the scriptlets entirely, but I still wouldn't care if the scripts that back it assume /bin/sh is bash.

We voted to state the obvious and define that /bin/sh is bash in Fedora. (+1:6, 0:0, -1:0).

I have problem with the reasoning. See request for changing rpmbuild/redhat-rpm-config to invoke /bin/bash by default https://bugzilla.redhat.com/show_bug.cgi?id=850706.

Basically the problem is executing bash as /bin/sh is not the same as executing /bin/bash (see bash(1) manual, especially POSIX keyword). Also it makes Fedora package non-portable because the scriptlet language does not match executed interpreter and exported package dependency.

I have two request:

(1) Remove the misleading parenthesized /bin/sh.

(2) Consider reverting this rule completely (or better replace with POSIX shell being the default), or make rpmbuild compliant to invoke /bin/bash instead of /bin/sh by default.

Currently any package produced by rpmbuild is possibly broken.

I think current sentiment is that we mean:

• We're executing the Bourne shell, /bin/sh
• The /bin/sh that we're executing is implemented by bash

So to the extent that bash extends the Bourne shell when run in this manner, we are fine with making use of these bash extensions. So:

• Do you have examples where the scripts published in the Guidelines fail when invoked by /bin/sh? The initial comment mentions "&>" which works with bash as /bin/sh.
• Do you see something from the guidelines that is unclear that we intend for things to be run with bash in POSIX mode (invoked as /bin/sh)? If so we can change the wording to make our intention (expressed above) more clear.

Closing for lack of response. If you do find examples of either of the above problems, feel free to open a ticket to have us clarify the wording or fix the scriptlet.