Yes, because it fixes the subshell usage of being a bit more compatible on a wider range. And rather than making the code more complex I would opt for
Is the code really more complex by this change? -%(chmod +x %_sourcedir/{@SCRIPTS@}) +%(cd %_sourcedir && chmod +x @SCRIPTS@) That's the bulk of the changes. I think the simpler chmod statement makes that one actually a tad easier to read, as you don't have to carefully parse brackets inside parentheses to understand what is going on. The other one is using unquoted " within " which is even recommended against in bash, where a single quote would work with any shell. I can also carry this as a local patch, but it is so minor that I don't think it adds any significant complexity. we're talking about 4 additional characters that, depending on how you see it, remove a {} construct that might be less obvious to understand also.
BuildRequires: bash-sh
that way there will be no surprises even for %().
that would make the kernel unresolvable and I'd have to carry a local patch to revert that so it would only make my work even harder than it already is. Also this would only work within the build service and would not make anything different for anyone using any other method of building the rpms.
While the kernel should be installable on a minimal system I don't see any reason why it should be buildable on a minimal system.
I agree with that. In order to test that it is installable on a minimal system in the buildservice, I need to have /bin/sh that way, because packages are installed at the end of the build and have their post install scripts executed. I'm near the bottom of this effort, the kernel is one of the last packages that still fails. It works for almost everything (I have about 10 failures including the kernel packages left of the ~ 3000 packages in the ring). I am not patching out complex and useful bash features here. These are hair sized changes that do not harm the understandability of the code. I'm not asking for a lot here, and while I do have a workaround of carrying a local patch and keeping the kernel that way, that costs me significantly more continuous work than upstreaming the change. And the change is not making your hard maintenance work any harder. you don't have to keep this working at all, and the lines I modified haven'T been touched in the last 11 years in git so they're certainly also not a big maintenance complexity for anyone else.
fact that kernel requires gcc (specific version, not clang), bison, openssl or dwarves to build does not offend anybody. In the same way I see no problem with requiring bash for build when it makes the build scripts simpler and more reliable.
I can submit a more minimal patch that is 6 lines change in total, no move of code tomorrow. I'm currently testing it. it will not add a single line of code, it will not move or remove a single line of code. it changes 4 characters in total per spec file. Thanks, Dirk