core: Use source root for repos if set #5284
Conversation
cgwalters
force-pushed
the
source-root-releasever
branch
from
8f82c3b to
242bef3
Compare
|
Cool, this makes things way less hacky for the cross build scenario! |
cgwalters
force-pushed
the
source-root-releasever
branch
from
242bef3 to
9209ef9
Compare
|
OK I updated this with more |
OK right of course this breaks the other compose paths, but hooray for CI. Digging... EDIT: I think I fixed that |
cgwalters
force-pushed
the
source-root-releasever
branch
from
0a99369 to
d70698d
Compare
Okay...now legacy treecompose works, but we somehow broke client side upgrades? Fun. EDIT: I think I figured that out |
cgwalters
force-pushed
the
source-root-releasever
branch
2 times, most recently
from
9960da1 to
557734d
Compare
| # In theory this can skew from the builder | ||
| FROM quay.io/fedora/fedora:41 as repos | ||
| # Demonstrate skew from the builder | ||
| FROM quay.io/centos/centos:stream10 as repos | ||
|
|
||
| # You must run this build with `-v /path/to/rpm-ostree:/run/build/rpm-ostree:ro` |
There was a problem hiding this comment.
Hmm, how about instead we mount an install tree and then rsync that in the container env? Similar to #5286.
There was a problem hiding this comment.
Yeah the CI sprawl is a huge pain. Lately what I've been thinking a lot about is getting really strict and saying: all build stuff is always in a container.
OK to just leave this bit for now and circle back to the larger CI problem...well, not sure when 😢 ?
The goal here is to have the new (more container-native) flow for `experimental compose rootfs` to always operate on a "repos container" that we've mounted. I noticed that `rpmostree_find_and_download_packages()` has similar behavior, but that's apparently only used in override flows? The only ugly workaround we need now is for the rpm-gpg stuff. Signed-off-by: Colin Walters <[email protected]>
This is a hacky workaround for two distinct bugs: - Needing /usr/share/rpm (because that's what rpm-ostree wants) in the repos container - gpgkey= not working with --source-root (see below) Closes: coreos#5285 It's called `--source-root-rw` because the way we expect this to work is in a Dockerfile, the `rw` flag will be set in `RUN --mount=type=bind,rw` to make a temporary overlayfs, so we can go ahead and mutate that root with our workarounds. Signed-off-by: Colin Walters <[email protected]>
cgwalters
force-pushed
the
source-root-releasever
branch
from
557734d to
1c6fae8
Compare
|
For the record, this one has some nontrivial regression risk. I was surprised that I initially broke package layering. Fortunately, our CI coverage is pretty good around this area. But, something to watch out for. |
core: Use source root for repos and dnf vars
The goal here is to have the new (more container-native) flow
for
experimental compose rootfsto always operate on a "repos container"that we've mounted.
I noticed that
rpmostree_find_and_download_packages()hassimilar behavior, but that's apparently only used in override
flows?
The only ugly workaround we need now is for the rpm-gpg stuff.
Signed-off-by: Colin Walters [email protected]
compose-rootfs: Add --source-root-rw
This is a hacky workaround for two distinct bugs:
in the repos container
Closes: #5285
It's called
--source-root-rwbecause the way we expect thisto work is in a Dockerfile, the
rwflag will be set inRUN --mount=type=bind,rwto make a temporary overlayfs, so we can go ahead and mutate that
root with our workarounds.
Signed-off-by: Colin Walters [email protected]