|
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
|
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
