-
Notifications
You must be signed in to change notification settings - Fork 50
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
depsolving: weak-deps selection #39
Conversation
6fc89ab
to
59ed28b
Compare
Initially applying this only to Fedora; I expect RHEL image builds to fail on this but the Fedora ones to come out correctly. |
01a5c08
to
6c23a34
Compare
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.
This is pretty amazing, tbh! :)
95d2344
to
c14301c
Compare
I've moved setting the |
c14301c
to
bf18ecb
Compare
Good idea. It'll be nice to be able to control this from the image definitions. We need to add |
So that was the route I initially took but it gets really murky really quickly as PackageSets are often appended to eachother and you might want PackageSet A to not have weak deps enabled and PackageSet B to have them enabled. For that reason I made it so you don't do that and the |
We discussed this outside the comments so I'll summarise here for the record.
In that case, these would be two package sets in the same chain (
The current behaviour makes the most sense. Say we start with a package set for a given purpose (build package set) and we know we want weak deps, so we set it to true. Anything we append to it after that can come from anywhere, but the primary purpose remains. So we should keep the logic of the |
bf18ecb
to
b3cd399
Compare
Wooo, it's green. Note the important bit: no images were built which means that there were no manifest changes with the code. |
b3cd399
to
5508ee2
Compare
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.
LGTM.
there is one cosmetic thing, but it can be changed in a follow up.
5508ee2
to
292e165
Compare
`dnf-json` had its own logic for determining which transactions to solve with weak dependencies enabled (only the first one). Move that logic into the Go code to make it easier to change which package specs get solved *with* weak deps (or without). A `PackageSet` now contains an `InstallWeakDeps` property that is propagated all the way down when depsolving.
292e165
to
9ac669b
Compare
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.
👍
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.
Thanks!
We want to be able to select if weak dependencies should be installed; currently
dnf-json
always enables weak dependencies for the first transaction in its depsolve (this is generally the packageset for the image type); let's make this configurable on the packageset(s) (and perhaps even in blueprints).The goal is to be able to turn off weak dependencies per image type.