-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for building an overlay RPM #414
Conversation
Used by: coreos/fedora-coreos-config#66 |
This is OK by me and makes sense to do now, but I also think the (inherent, not your fault!) ugliness of building RPMs is a strong argument for 1788. |
What's the plan for handling setting permissions? It probably makes sense to allow relaxed privilege on the files themselves (so you don't need root to edit) but changing them when building the rpm to what they should be on the system. |
rpm defaults to files being owned by root, even when building as a non-root user. |
764d92e
to
024d0ac
Compare
What about mode? |
This patch adds support for an overlay RPM defined by a rootfs in the source repo at `overlay/`. Unlike FAH, FCOS is much more opinionated about various things. And these opinions express themselves through e.g. config file overlays, systemd units, Ignition base configs, etc... These files don't clearly belong in any particular "component" package, but rather provide the glue that makes FCOS feel like FCOS. This is similar to CL's [init](https://github.com/coreos/init) package. Right now, a lot of these files are just written out as part of the postprocess script in the treefile. Splitting them out has the major benefit of being able to track them in the rpmdb so one actually knows where they come from. It'd also mean a cleaner manifest and easier hacking on those files and tracking in git. We can probably teach rpm-ostree to do this directly later on and deprecate/automatically translate `add-files` along with it.
024d0ac
to
81895fd
Compare
OK, dropped WIP on this!
|
OK, that's not entirely correct. It looks like it only records the owner executable bit on files:
So I guess any other mode bits we'd have to record through |
One thing this will likely trip is the "all rpms in rpmdb are signed" thing but...eh, we can change that to lie later 😉 LGTM! |
Thanks! Any other comments on this one? |
Otherwise we'll error out if the user has no overrides. Regression from coreos#414.
Follow-up in #555 to switch to use an OSTree layer. |
This patch adds support for an overlay RPM defined by a rootfs in the
source repo at
overlay/
. Unlike FAH, FCOS is much more opinionatedabout various things. And these opinions express themselves through e.g.
config file overlays, systemd units, Ignition base configs, etc... These
files don't clearly belong in any particular "component" package, but
rather provide the glue that makes FCOS feel like FCOS. This is similar
to CL's init package.
Right now, a lot of these files are just written out as part of the
postprocess script in the treefile. Splitting them out has the major
benefit of being able to track them in the rpmdb so one actually knows
where they come from. It'd also mean a cleaner manifest and easier
hacking on those files and tracking in git.
We can probably teach rpm-ostree to do this directly later on and
deprecate/automatically translate
add-files
along with it.