On 8/20/24 00:04, Luis Chamberlain wrote: > On Fri, Aug 16, 2024 at 12:20:01PM +0200, Ole Schuerks wrote: >> What's the best way of letting the user know that they need to >> install PicoSAT if they want to use the conflict resolver? >> My idea would >> be to notify the user via the GUI when they try to use the interface of >> the conflict resolver without having PicoSAT installed. Do you see any >> issues with that/do you prefer some alternative approach? > > Conflicts don't happen often and we already have a printf which happens when > one does, my recommendation would be that we simply opt-in for the > resolver if the user has the requirements installed. Otherwise we only > inform the user to install it if a conflict comes up. Documentation can > also be enhanced to describe this functionality / support. > > Luis There's perhaps a misunderstanding here. I think you are talking about the rare scenario where a symbol is selected despite the dependencies not being met (where the printf tells you that). But ConfigFix isn't only useful in this case. We believe that the most common use will be to enable or disable symbols with missing dependencies that prevent directly setting the symbols' values via the GUI. For example, when one symbol depends on a second symbol, and the second symbol is set to N, then the first symbol cannot directly be set to M or Y (assuming it isn't already selected by some symbol). One case of such a constellation is DEBUG_MISC, which depends on DEBUG_KERNEL. ConfigFix can identify that DEBUG_KERNEL must be set to Y in order to set DEBUG_MISC to Y. Conflicts can also occur when trying to lower the value of a symbol: If a symbol is selected by a second symbol, and the second symbol is set to Y, then the first symbol can't directly be set to N or M. One such case is EXPERT, which selects DEBUG_KERNEL. So, the conflict resolution is useful when users want to quickly enable some grayed out symbols. If one has to install some external package first, then that might diminish the usefulness. While there are extreme cases where it can take hours to manually identify all the dependencies, first having to build PicoSAT might take longer than manually resolving the conflict. Many users might then never install PicoSAT to try out the conflict resolver, even if they would benefit from it. So the question is whether using PicoSAT as an external library is worth the portability issues and effort, and whether it wouldn't make more sense to directly include the PicoSAT source file. Otherwise, if we go with not including the PicoSAT source, then one could inform users about the missing package in the GUI, like this: When PicoSAT is installed: https://drive.google.com/file/d/1asBfLp1qfOq94a69ZLz2bf3VsUv4IYwL/view?usp=sharing When PicoSAT is not installed: https://drive.google.com/file/d/1ytUppyFPtH_G8Gr22X0JAf5wIne-FiJD/view?usp=sharing Let us know what you think. Include PicoSAT directly as a source or not, and then inform the user via the GUI?
