Hi, I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast. Someone has tried an old AutoYast profile with <sshd/> settings and was surprised not to have sshd configured accordingly. They have asked for getting a warning / error report about it. There are several possibilities how to solve it with different level of benefit for the customer, maintenance effort in the future and cleanness of the solution. 1. Handle only sections known to be dropped Benefit: Inform about dropped support of <sshd/>, ...? Solution: Hard-coded list of dropped sections Effort: Low Maintenance: List of dropped modules Disadvantage: Doesn't report unknown sections 2. Compare the profile with what the currently installed system can configure Benefit: Inform about all unknown sections and also known sections that cannot be handled because of some missing Yast packages Solution: Using the current AutoYast functionality for parsing desktop files that maps "X-SuSE-YaST-AutoInstResource" entries to the profile (Y2ModuleConfig.ModuleMap.keys - Profile.current.keys - ["globals", "language", "networking", "user_defaults" ...]) Effort: Medium Maintenance: Hard-coded list of false-positives Disadvantage: The current implementation doesn't seem to recognize some entries, such as ["globals", "language", "networking", "user_defaults" ...], for instance, "language"/"keyboard" is hard-coded in clients/inst_autosetup.rb 3. Compare the profile with currently installed schema Benefit: Handle only unknown sections Solution: Parse /usr/share/YaST2/schema/autoyast/rng/profile.rng that should already contain all known sections Effort: Hard(er) Maintenance: Either hard-coded list of false-positives or schema Disadvantage: XML parser to read and understand profile.rng, but profile us not up to date anyway, e.g., <globals/> is missing there. I like the #2 the most, but fixing Yast to correctly evaluate some entries could lead into change of the current behaviour. There is too much hard-coded information now. So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;) Thx Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org