On Mon, Mar 25, 2019 at 08:18:34PM +0000, Tomasz Kłoczko wrote:

Switching to other than bash sh interpreter allow reduce total gcc package
build time by ~5%.

OK. But that just shows that it is — possibly — worth to switch the gcc build
to a different shell, by working with gcc upstream. Nothing should be
extrapolated from this to other packages and in particular to their
spec files.

But why not? It's obvious that anything with a lot of forking and subshelling in it will be improved. Back when ash was part of the distribution I regularly got 30-35% concurrency improvements on resource-strained machines when my service had an unavoidable fork or three in it. (Looking at you, qmail.) I mean, nothing about https://wiki.ubuntu.com/DashAsBinSh has actually changed in all these years, really.

It feels like there's been this vast movement to try to remove every last bit of shell from Fedora whenever possible, and I really don't understand the aversion. True, sometimes the the best answer to a dilemma about how to improve XYZ is "mu - let's remove XYZ", but a slavish devotion to that has some significant drawbacks. (It was mentioned above that Fedora found a much better way to deal with boot times, and I'd have to disagree. If you can take a one-time hit to remove bashisms and get a 25-40% improvement, that seems a far better deal than the years of misery and Linux civil wars the alternative precipitated.)

Transactions are nice, but they're not everywhere, and won't solve every issue a .spec might have. And that's certainly not necessarily the case for non-Fedora code. Given that shell won't ever really completely go away, there's nothing wrong with evaluating ways to increase compatibility, quality, and efficiency in our execution choices.

Part of that begins with ensuring mechanisms are in there for local SAs to hook useful decisions into. And making this more explicit allows both the RPM format and Fedora's relation to it to be better defined.

-jc