Mailinglist Archive: yast-devel (72 mails)

< Previous Next >
Re: [yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
Hm, I would be more pragmatically here.
Please keep in mind that the autoinst.xml file will be generated just
one time
by a very experienced person.
From my point of view an error message like:
"AutoYaST section <section_name> cannot be handled because
<absolute path to section_name_auto.rb> cannot be found. It seems that
the needed package has not been installed"

Then the admin will have a look which package supports that file and why
the package has not been installed.
(May be there could be a package conflict too :-))


Am 23.04.2015 um 10:05 schrieb Jiri Srain:
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 ;)


To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups