dracutdevs / dracut

dracut the event driven initramfs infrastructure
https://github.com/dracutdevs/dracut/wiki
GNU General Public License v2.0
604 stars 400 forks source link

Dependence on Bash #464

Closed GravisZro closed 4 years ago

GravisZro commented 6 years ago

Despite there even being a module for Dash, Bash is still required to actually execute Dracut. It wouldn't be a herculean effort to simply replace the Bashisms with POSIX conformant shell code.

haraldh commented 6 years ago

I can see the benefit of only having dash in the initramfs. And we committed to that. Why exactly do you want us to jump through hoops?

GravisZro commented 6 years ago

Bashism are non-standard and therefore will not work on shells that are not Bash. Not everyone uses Bash.

danimo commented 6 years ago

I think Harald's question was quite to the point: Is there a specific situation that you are in where bash is not an option for other reasons than some weird feeling that bash should somehow not be required on Linux? Dracut is quite complex for a shell project and foregoing bash specific would make it even more complex.

GravisZro commented 6 years ago

It seems bizarre that I have to argue in favor of standards compliance. Have we learned nothing from the days of "only works with Internet Explorer" websites?

awilfox commented 6 years ago

My knee-jerk is recovery environments that only have dash (i.e., the initramfs), or BusyBox (i.e., Alpine or Debian recovery shell). If you need to regenerate your initramfs image for any reason from those environments, you can't do it unless you have Bash.

haraldh commented 6 years ago

I accept patches :smiling_imp:

awilfox commented 6 years ago

Will you? That emoji, and the "laugh" response, suggest that you think this is a joke.

It's not a joke, and to me that reflects very poorly on supporting Dracut as our primary initramfs generation system for our distribution.

haraldh commented 6 years ago

Well, the emoji was only, because I don't want to do the work.

johannbg commented 4 years ago

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

GravisZro commented 4 years ago

Dependence on Bash is still a problem.

johannbg commented 4 years ago

Feel free to submit a pull request that addresses that problem which will get reviewed and merged like issue #507

GravisZro commented 4 years ago

Why did you close the issue? It's a still a problem.

johannbg commented 4 years ago

It's a problem that will be addressed via pull requests which no one has care to do for the past 2 years including yourself and there is no interest or apparent need for upstream to do that work and it's serves no point keeping issues open that no one is working on just for the sake of keeping them open.

If and then when someone decides to rewrite dracut to be based upon "POSIX conformant shell code" that work will be reviewed just like any other PR.

GravisZro commented 4 years ago

Just because nobody has addressed the issue yet doesn't mean it's not an issue. Closing this only hides the issue, it does not resolve it.

johannbg commented 4 years ago

That perspective is entirely dependent on the report being viewed as being an issue to begin with...

GravisZro commented 4 years ago

If we've learned anything from the Browser Wars, it's that dependency on non-standard proprietary extensions resulting in lock-in should be viewed as a problem for everyone.

awilfox commented 4 years ago

This could easily be a tracking bug. Having it open could generate eventual interest from others.

Personally, it's been on my list of "things I could do on a rainy day" for a while. It's true that I have not yet done it. Sometimes my "rainy day" projects wait 5 years or more. But I do try to actually do them some day.

However, the overall tone from Dracut maintainers and contributors in this thread do not entice me to actually put that effort in. Dismissiveness and deriding people who want to improve a project and enable it to work in more situations that are entirely in-scope for its overall purpose is not a great way to attract new contributors. (I've actually written an entire article on this phenomenon.)