How would we feel about just packaging and adding /usr/bin/rpmostree-dracut-wrapper as a separate file in the repo? about rpm-ostree

[dougsland]

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)

https://github.com/coreos/rpm-ostree/blob/54047f83ea812d31e5bfd85878a440bb2f3cf1ec/src/libpriv/rpmostree-kernel.cxx#L471C16-L471C20

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).

@jlebon @cgwalters @dougsland

make sense to my eyes. It helps simplicity and modularity.

[cgwalters]

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 --reproducible if available - first we can just hardcode the availability of --reproducible nowadays, but even that is also configurable

There's also some juggling of writing to a temporary fd but we can do that in callers.

[cgwalters]

, 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.