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 installations?
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 configure
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.
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 profile 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 the 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 yast2-ssh 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. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org