On 01/23/2018 03:11 PM, Alec Warner wrote: > I'm starting to be a bit sad about this for a couple of reasons. > > 1) dep_zapdeps is pretty big at this point, and every tweak for || () > just grows it. Do we have any idea: > a) When dep_zapdeps will be 'done'?
We're gradually approaching a point were it can't be improved much more, without major refactoring. > b) Plans for splitting it into more manageable pieces? The next step is to evaluate the overlapping || deps for multiple packages at the same time, using DNF. That will be a good time for refactoring. > 2) In general I worry that the logic for || () will essentially never be > complete, and we will be forced to tweak the implementation forever as > cases arise where the algorithm fails to compute the 'right' answer. > I'm a bit curious what 'right' even is anymore. The devmanual doesn't > really describe how any-of dependencies are resolved and so the changes > seem rather arbitrary. The 'right' answer is optimal in the sense that it: 1) Installs the minimum number of packages necessary 2) Upgrades all packages to the latest version possible 3) Prefers choices toward the left when there's no overriding reason to do otherwise (1 or 2 above) > I am not worried about specific changes (like > this one) but the fact that we continually apply changes to make the > 'right' thing happen is the larger concern. I'd worried if we didn't have unit tests which prove that it's behaving optimally for that cases that it's designed to handle. It's gradually approaching the point where we can't change the behavior much without making it behave sub-optimally for some of our existing test cases. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
