Mailinglist Archive: yast-devel (72 mails)

< Previous Next >
Re: [yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
On Thu, 23 Apr 2015 10:23:35 +0200
Stefan Schubert <schubi@xxxxxxxxxx> wrote:

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"

Well, it is more confusing message, as autoyast install yast packages
that they need, so we should report that section is no longer supported
and won't be configured.


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

I hope in case of conflict we report it to user anyway, not?

Josef


Greetings
Stefan



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





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

< Previous Next >
Follow Ups