On 3/25/2019 2:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
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