Mailinglist Archive: yast-devel (72 mails)

< Previous Next >
Re: [yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
On 04/17/2015 04:16 PM, Lukas Ocilka wrote:

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
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

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).


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 ;)



Jiri Srain
Project Manager
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxxx
Lihovarska 1060/12 tel: +420 284 084 659
190 00 Praha 9 fax: +420 284 084 001
Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >