3 ms·
One potential problem with dependency resolution that focuses solely on minimal or maximal-bound resolution is that it usually ignores the untested version comb
by binarycrusader 9y ago
One potential problem with dependency resolution that focuses solely on minimal or maximal-bound resolution is that it usually ignores the untested version combination problems.
That is, a given version that satisfies a version bound may not have necessarily been tested with all of the different combinations of versions of components it is used with. It will be interesting to see how minimal version selection interacts with that particular challenge. For a build system it may matter much less than an operating system.
- munificent 9y agoAs far as I know, that problem is effectively unsolvable. For most real-world-sized dependency graphs, the set of all valid combinations of dependency versions is heat-death-of-the-universe huge.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- binarycrusader 9y agoThe way the system I worked on "solved it" was to provide another layer of constraints called "incorporations" that effectively constrained the allowed versions used to resolve dependencies to a version that was delivered for a given OS build. Administrators could selectively disable those constraints for some packages, at which point resolution was solely based on the "standard" dependencies. But by default, dependencies would "resolve as expected". The "incorporate" dependencies are described here: https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes.html#gluna https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes...