Skip to content
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

deploy: Only hold local variant pointer, not in struct #3036

Merged
merged 2 commits into from
Aug 1, 2021

Conversation

cgwalters
Copy link
Member

@cgwalters cgwalters commented Jul 28, 2021

deploy: Only hold local variant pointer, not in struct

This is part of reducing the number of places that need to
be touched when adding new API. There's no good reason to parse
the options variant into a struct member; we can just keep
it as a local variable.


origin: Make some package/module mutation functions no-ops for NULL

Rather than having the caller do conditionals for NULL, do it
inside the function. This simplifies the control flow and avoids
duplication.


@lucab
Copy link
Contributor

lucab commented Jul 29, 2021

If we agree on this one, there are a lot more to do like this.

LGTM, though this kind of changes do not seem controversial to me, so maybe I'm missing something subtle. I'm reading this patch in the context of minimizing data lifetime/scope in order to reduce the amount of action-at-a-distance side-effects (and thus subtle bugs).

@jlebon
Copy link
Member

jlebon commented Jul 29, 2021

Yup, makes sense. Did something similar in #3006 (well, it's still structs, but it moves unpacking and conflicting options checking to deploy_transaction_execute -- definitely can fold the unpacking part into rpmostree_callimpl_update_deployment). You can reduce DeployTransaction to something like this: https://github.com/jlebon/rpm-ostree/blob/42ea8747d932ddc6fa7ed663bb6a3b2b3b79c92c/src/daemon/rpmostreed-transaction-types.cxx#L595-L602.

lucab
lucab previously approved these changes Jul 29, 2021
@cgwalters
Copy link
Member Author

Ah OK wow yep, the changes in #3006 look good! Do you want to try to factor that out, or I could, or we could merge a few things like this and then you rebase later?

@jlebon
Copy link
Member

jlebon commented Jul 30, 2021

Ah OK wow yep, the changes in #3006 look good! Do you want to try to factor that out, or I could, or we could merge a few things like this and then you rebase later?

If you have cycles right now, feel free to do either of the last two (you factoring it out or merging stuff in and I'll rebase). Otherwise, I can probably pick this up next week as part of #3006 since it looks like there's some agreement on a path forward there.

This is part of reducing the number of places that need to
be touched when adding new API.  There's no good reason to parse
the options variant into a struct member; we can just keep
it as a local variable.
Rather than having the caller do conditionals for `NULL`, do it
inside the function.  This simplifies the control flow and avoids
duplication.
@cgwalters
Copy link
Member Author

OK. Hmm. Since this is a lot of code to touch let's try doing it incrementally. I pushed two smaller cleanup patches here.

@@ -809,6 +809,8 @@ rpmostree_origin_remove_packages (RpmOstreeOrigin *origin,
gboolean *out_changed,
GError **error)
{
if (!packages)
return TRUE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This bit is missing for rpmostree_origin_add_packages for consistency. Though meh.. kinda leaning towards not even having it since the code already handles it fine. But obviously fine as is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, will look at this in a followup!

@cgwalters cgwalters merged commit cbf7485 into coreos:main Aug 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants