Add overrides/rootfs #521
Add overrides/rootfs #521
Conversation
i.e. coreos/rpm-ostree#1645 and enabling that mechanism to overwrite files? |
Yeah I linked the PR to that issue, though your second point i we should probably explicitly separate |
oh cool, thanks. From just reading the PR titles (rpm-ostree is the last repo I haven't caught up on since leave) I didn't realize
Yeah I think it would be worth making a distinction. It is a problem I've hit with |
|
Definitely like the idea of being able to
Hmm, let's discuss this in coreos/rpm-ostree#1645? AFAIK, the UX itself would be the same regardless on the cosa side. |
cgwalters
force-pushed
the
bin-overlay
branch
2 times, most recently
from
5f98efe to
cdc8b47
Compare
|
🆕 Updated and is working for me! I'm playing with a new workflow which is (from my rpm-ostree builddir): This itself is incremetal step towards either having cosa grow support for something like: |
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds to rpm-ostree the ability to inject ostree refs into the build. We could implement this in cosa by building an RPM (like we do for the overlay mentioned above) but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time.
|
LGTM! |
This is strongly related to coreos/fedora-coreos-config#66
For development iteration, we want the ability to directly overlay
binaries. This depends on
coreos/rpm-ostree#1830
which adds rpm-ostree ability to inject ostree refs into the build.
We could implement this in cosa by building an RPM but I think that's
silly - we end up compressing the data only to immediately decompress it.
Plus, while there are advantages to having entries for files in the RPM
database, in practice we're lying about having these files built by RPM.
So let's just directly generate an OSTree commit from them and inject
that.
(In practice for this use case rpm-ostree could actually learn
a way to directly consume a directory, but indirecting via OSTree
means it's equally easy to manage pre-generated ostree branches too
in an efficient way rather than re-committing each time)