Merge SAT vars for each package #153
Conversation
|
| "A": []string{"0:1.0-1"}, | ||
| }) | ||
| expectedVars(g, model, "A-0:1.0-1(A)") | ||
| expectedVars(g, model, "A-0:1.0-1") |
There was a problem hiding this comment.
This parenthesis requirement duplicates appears on real RPM requires, I feel dropping this from tests may actually break real resolution
Why are you dropping them?
There was a problem hiding this comment.
Not sure what do you mean :(
This follows directly from the change in func (v Var) String() string, as Var no longer has info about specific resources the package provides.
Is there some case not covered by tests?
There was a problem hiding this comment.
This is what I mean https://g.co/gemini/share/f453cd2e46af, as you can see an RPM may say it depends on feature(modifier) I think we're dropping the modifier part with this change set, we will only notice the breaking change at runtime not while rendering the required RPMs
There was a problem hiding this comment.
I think that at no point bazeldnf parses the content of provides/requires/conflicts name, so there's no place to drop that modifier.
What this change does for e.g. glibc-related SAT variables, would be this transformation of a debug string for Var struct. For example:
SAT variables:
glibc(libc.so.6(GLIBC_2.16))glibc(libc.so.6(GLIBC_2.17))- …
will be replaced by single one: glibc.
The info about particular resource provided (e.g. libc.so.6(GLIBC_2.16)) is now processed only at the previous stage of SAT construction – in the ProvidedResource struct.
The intention of this change is to keep behaviour the same, while simplifying the internals.
There was a problem hiding this comment.
I have to echo @manuelnaranjo 's comment - it looks like in some of the later tests we're previously expecting multiple distinct qualifiers for the same package? The belief is that theyre not being used?
| expectedIgnores(g, model) | ||
| expectedAnds(g, model, | ||
| bf.Eq(x1, x2), // Equivalence (platform-python) | ||
| bf.True, // Nothing to install |
There was a problem hiding this comment.
what is causing this change and why is it desirable?
| "A": []string{"0:1.0-1"}, | ||
| }) | ||
| expectedVars(g, model, "A-0:1.0-1(A)") | ||
| expectedVars(g, model, "A-0:1.0-1") |
There was a problem hiding this comment.
I have to echo @manuelnaranjo 's comment - it looks like in some of the later tests we're previously expecting multiple distinct qualifiers for the same package? The belief is that theyre not being used?
aszady
force-pushed
the
collapse
branch
3 times, most recently
from
47dc06a to
afe46ee
Compare
Variable generation is separated into two parts: - extracting `Resource`s provided by the package – data most useful for the `Loader`; - creating SAT variable related to that resource – data most useful for the `Resolve` (`Model`). This modularization of code should facilitates future code changes. The `VarTypeResource` vs. `VarTypeFile` distinction was not used, therefore these were merged for further simplification.
SAT construction used an implication that one provided dependency implies all dependencies from that package. That's effectively an equivalence relation between all these variables and thus can be merged into one. This reduces generated SAT size a bit. //pkg/sat:sat_determinsitic_test runs ~3× faster; //pkg/sat:sat_test runs ~30× faster.
3 participants
SAT construction used an implication that one provided dependency implies all dependencies from that package. That's effectively an equivalence relation between all these variables and thus can be merged into one.
This reduces generated SAT size a bit.
//pkg/sat:sat_determinsitic_test runs ~3× faster;
//pkg/sat:sat_test runs ~30× faster.