On 04/17/2015 04:16 PM, Lukas Ocilka wrote:
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
I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules. Then you would need to maintain such list for each product separately. Short-term solution / quick hack OK if necessary, but I'd avoid it.
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
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
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.
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here. OTOH, we have a single profile per code stream, not per product (which will fail in case of module being part of some products only). HTH, Jiri
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
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org