Hello, On Thu, Mar 17, 2022 at 10:06:09PM +0100, Dirk Müller wrote:
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@)
slightly
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.
That's completely subjective
The other one is using unquoted " within " which is even recommended against in bash, where a single quote would work with any shell.
I am not against improving readability of shell code in general, and this may fall in that category
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.
So long as you build rpms the dependencies should be fulfilled so it will work for any method that builds rpms. If you don't build rpms you supply your own build scripts and you are free to write them in any language you choose.
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,
Buildservice is a build environment, not a test environment. By testing in buildservice you are conflating build time and runtime. Please use the correct tool for the job. It's not like we don't have any.
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 suppose those 10 are those that actually use non-trivial scripting during the build.
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.
And when one of the alternative shells subtly breaks some of the code that is not explicitly executed in bash because there is no way to specify the interpreter for it will you also request that the kernel carries compatibility cruft for such breakage? Where do you draw the line? I don't support building with anything but bash, to reduce maintenance effort. Now that the distribution grew /bin/sh alternatives I will request that for kernel build /bin/sh is bash, always. Thanks Michal