How would we feel about just packaging and adding /usr/bin/rpmostree-dracut-wrapper as a separate file in the repo?
Opened this issue · 3 comments
We could even put it some place like /usr/lib/dracut/rpmostree-dracut-wrapper if we wanted to hide it from the user's PATH, (or even just /usr/lib or some other alternative)
We are gonna have to add ~2-3 lines to that shell script for initoverlayfs, it's somewhat error-prone converting bash text to a C string literal and not great to read (and it can't be statically analysed either using things like shellcheck if people want to do that).
We could even put it some place like /usr/lib/dracut/rpmostree-dracut-wrapper if we wanted to hide it from the user's PATH, (or even just /usr/lib or some other alternative)
We are gonna have to add a ~2-3 lines to that shell script for initoverlayfs, it's somewhat error-prone converting bash text to a C string literal and not great to read (and it can't be statically analysed either using things like shellcheck if people want to do that).
make sense to my eyes. It helps simplicity and modularity.
Hmm, I think nowadays we could aim to kill that wrapper actually. It does basically 2 things:
- Forces
--add ostree: but this same effect can be done by embedding static grub configuration (fcos base example), and I think we should recommend this. - Adds
--reproducibleif available - first we can just hardcode the availability of--reproduciblenowadays, but even that is also configurable
There's also some juggling of writing to a temporary fd but we can do that in callers.
, it's somewhat error-prone converting bash text to a C string literal and not great to read (and it can't be statically analysed either using things like shellcheck if people want to do that).
This is true; on the Rust side it's trivial to use include_str! for this type of stuff at least. (There is e.g. GResources with glib but it's comparatively heavyweight)
I don't have a really strong opinion; if you want to both split it to a separate file and install it, that's fine. But porting to Rust or GResources would allow splitting it without also installing it as a separate binary.