-
Notifications
You must be signed in to change notification settings - Fork 198
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
Introduce compose rojig
#1512
Introduce compose rojig
#1512
Conversation
☔ The latest upstream changes (presumably d2b0e42) made this pull request unmergeable. Please resolve the merge conflicts. |
f2a81cd
to
23a1a64
Compare
OK, this is updated again. The complexity in The biggest pieces here are:
What I find myself wondering though is if we really need to support the case of "compose both to ostree and rojig" here. If we didn't support all 3 cases, it might end up cleaner to refactor to separate C files with shared helpers. Anyone who wants to do both could just do rojig via There's no tests yet but I have been testing this with some local silverblue 29 builds. |
23a1a64
to
77cc421
Compare
Test ✔️ added, lifting WIP. |
I haven't reviewed this yet -- can it wait until after the release? |
Yep. |
I think this is probably GTG as is, but we could consider making it more invasive. |
return FALSE; | ||
DnfContext *dnfctx = rpmostree_context_get_dnf (corectx); | ||
if (!glnx_shutil_mkdir_p_at (self->workdir_dfd, "rojig-repos", 0755, cancellable, error)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, would be nice to enhance libdnf so we don't have to do this.
{ | ||
if (!opt_ex_rojig_init) | ||
{ | ||
g_autofree char *rojig_name = ror_treefile_get_rojig_name (self->treefile_rs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to factor all this out into a separate function.
@@ -1698,7 +1770,8 @@ rpmostree_compose_builtin_tree (int argc, | |||
return FALSE; | |||
} | |||
|
|||
if (!opt_repo) | |||
const char *rojig_outputdir = opt_ex_jigdo_output_rpm ?: opt_ex_jigdo_output_set; | |||
if (!opt_repo && !rojig_outputdir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The various combinations of --repo
, --ex-rojig-output-rpm
, --ex-rojig-output-set
, --cachedir
, --workdir
, --unified-core
is hard to fully comprehend. I'm wondering if there are any ways we can split these flows apart now into distinct functions (or even files) across e.g. unified/non-unified, or ostree/rojig?
OK, and now I reread your older comment which mentions exactly this:
What I find myself wondering though is if we really need to support the case of "compose both to ostree and rojig" here. If we didn't support all 3 cases, it might end up cleaner to refactor to separate C files with shared helpers.
Yes, I think that makes sense to me. The major case I can imagine where you want both ostree and rojig is to reduce friction when transitioning from one to the other. But as you mentioned, one can still use commit2rojig
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK so: split off a prep commit that drops the functionality, or do it in one go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Splitting off would be nice, though if it's too entangled, doing it in one go is fine.
self->previous_version = g_strdup (dnf_package_get_version (rojig_pkg)); | ||
self->previous_inputhash = g_strdup (rpmostree_context_get_rojig_inputhash (corectx)); | ||
} | ||
else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just drop --ex-rojig-init
and enhance the core so we can discern the ENOENT
case from other errors? Then it'd be fully symmetrical with the --repo
case.
☔ The latest upstream changes (presumably 16f48af) made this pull request unmergeable. Please resolve the merge conflicts. |
77cc421
to
bfc22b3
Compare
This conceptually depends on #1574 in that right now |
☔ The latest upstream changes (presumably 8df07a3) made this pull request unmergeable. Please resolve the merge conflicts. |
bfc22b3
to
9be5d26
Compare
☔ The latest upstream changes (presumably 0a050d8) made this pull request unmergeable. Please resolve the merge conflicts. |
9be5d26
to
4c1e575
Compare
☔ The latest upstream changes (presumably b5d34b7) made this pull request unmergeable. Please resolve the merge conflicts. |
39a137e
to
1bd46b4
Compare
OK, lifting WIP on this. |
☔ The latest upstream changes (presumably 87441d9) made this pull request unmergeable. Please resolve the merge conflicts. |
1bd46b4
to
c31d7ae
Compare
if (!glnx_shutil_mkdir_p_at (self->workdir_dfd, "rojig-repos", 0755, cancellable, error)) | ||
return FALSE; | ||
{ g_autofree char *repopath = g_strconcat ("rojig-repos/", rojig_output_repo_id, ".repo", NULL); | ||
g_autofree char *repo_contents = g_strdup_printf ("[%s]\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thinking out loud here: this is just to find the previous rojig RPM, right? Hmm, I wonder if we could avoid this hack somehow by using dnf_sack_add_cmdline_package()
instead. Another plus is that one doesn't have to createrepo_c
the outdir first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd have to scrape the dir still to find the latest...and at some point one needs to run createrepo_c
to serve to clients.
Looks sane to me, though the tests are hitting:
Sounds like it didn't test on top of the latest Rust PR? Anyway, Homu should rebase it, so let's give it a try. |
This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
💔 Test failed - status-atomicjenkins |
This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it.
147d201
to
4740e6e
Compare
They actually did conflict, the @rh-atomic-bot r=jlebon 4740e6e |
This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
💔 Test failed - status-atomicjenkins |
Now with actually pushing my fixup... |
☀️ Test successful - status-atomicjenkins |
Starting to implement #1237