Today I was shocked again (as it happens most days of my life). I saw how an academic research group working mainly on the area of computer security have configured their own IT systems. Obviously I cannot go into details here but I can repeat my general advice to all people working on theoretic concepts to at least apply these concepts they are publishing papers on it to their personal practice. If you don't do so, you definitely will lose contact to reality...
Another thing I thought about today was how to improve dependency resolving in our build system. Currently we are doing basic dependency checking with a greedy algorithm that continuously takes the decision required to resolve a dependency as long as it is not ambiguous. If the decision is ambiguous the resolver stops and requests manual specification. This does work and is implemented by most RPM install tools as well. But for a build system it becomes more and more annoying the more distributions it supports because every distribution likely adds some more ambiguous choices. The alternative some other build systems use is to hard code some special selection rules is not really better because it tends to blow the rules for each additional distribution you add. My current idea is to convert all package dependencies into linear equations, adding an objective function to minimize the number of packages, and then solve the simplex matrix by a linear solver. This would definitely give a generic algorithm and converting dependency rules to linear equations is straight forward. To prevent the solver from selecting one solution randomly if there are multiple minimal sets possible, I might give some extra weight (< 1/(total number of packages)) in the objective function to the packages. Nice thing with these idea is that it will work with any package management system, solving the sparse simplex matrix should be acceptable fast with good solvers, and you don't need any user interaction as long as the dependencies are solvable.
No comments:
Post a Comment