Mailinglist Archive: yast-devel (72 mails)

< Previous Next >
Re: [yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
On 23.4.2015 10:45, Ladislav Slezak wrote:
Dne 23.4.2015 v 10:05 Jiri Srain napsal(a):
1. Handle only sections known to be dropped
I don't really like this section because different products (even SLES vs.
SLED) may
have different YaST modules.

I do not think this is a problem, if we want to support just dropped modules
than it's OK (if we drop a module it's dropped from both SLES and SLED).

IIRC the profiles should be created on a machine with the same product,
do we really support creating profile on SLES and using it for SLED

The validation cannot be 100% perfect, e.g. some packages are SLES or SLED
only, but the software section structure is the same for both...

You're right that the bugreport is about module that has been dropped,
but the user did not know.

On the other hand, I'm looking for additional value to the customer.
AutoYast is a big beast with a lot of "grey behaviour". When I'm
touching some part, I want it to be better than before. Reporting that
<sshd> has been dropped solves the current problem, but only that one.

The question is: How much do we care? I myself would like to save some
development/debugging time in the future.

2. Compare the profile with what the currently installed system can

I think that this option looks best to me, since it honors also "what is
installed" and reports an error in such case. I don't think that any of the
options inform you when the package selection is the reason why something
cannot be

I agree it's better than 1., but it's more complicated for implementation...

As I said in the original e-mail, this is a preferred solution for me,
but it has pros and cons. The biggest advantage is that it provides
dynamic information based on the current installation/profile. For
instance, if some package is missing in the profile, then user will find
out easily without reporting an L3.

3. Compare the profile with currently installed schema

One thing I like on this approach is that it will force us to keep the
up-to-date, I don't think that we are doing a good job here.

That's true. On the other hand I know that some customers use AutoYast in many
crazy situations... BTW what about the possible 3rd party AY modules? AFAIK
schema is generated only for our modules...

Good point with 3rd party modules.

IMHO we are a bit over engineering here, the initial issue was dropped
module, solution 1. should be enough for this case...

My intention is to provide a generic solution without need to touch the
code every time we change something. Hard coding some non-generic
information is IMO a way to hell. AutoYast should behave similarly to
Installation - just a framework. The current code often doesn't look
like that.

Would it pay off? That's the question.



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 >