Mailinglist Archive: yast-devel (72 mails)

< Previous Next >
[yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >