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...
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...
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... IMHO we are a bit over engineering here, the initial issue was dropped yast2-ssh module, solution 1. should be enough for this case... -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org