Thanks for your quick answer, Klaus, On Thursday 06 November 2008, Klaus Kaempf wrote: > > Not quite. The rule is: YaST should be there, even in a minimal > installation, to guide the user.
With "YaST should be there" meaning: "all modules that we declare useful should be installed by default"? > The use case is: > User does a minimal, textmode installation. Maybe because of limited > bandwidth, maybe because its a headless (without graphics card) > server. Now he wants to configure X11. YaST is there to help and on > starting yast2-x11, the user is prompted to install missing packages. Ok, got the idea. From my point of view the usecase is (slightly different): User does a minimal installation, because of ...xy... and this minimal installation does not include yast2-x11 (nor its requirements). Now he wants to configure X11 and therefore installs the needed packages which automatically pull in all requirements. But I see that it makes things uncomfortable for eg. the unexperienced user who did a minimal installation and now wants to configure X11 but can not find anything to start with. I think we should discuss this issue again later when we have a solution like the following consistent and working in our distribution(s): http://kobliha-suse.blogspot.com/2008/08/yast-can-list-not-yet-installed-modules.html > Now the question is: Should a YaST module do the test for missing > packages at every start ? > I'd say no ! I'd say yes :) > This test should only be done at first start. If there's > already a configuration (e.g. for X11), the YaST module should assume > all packages are installed and user wants a reconfiguration only. Assuming, that something is there creates lots of funny errors that are not fun to debug! Testing for missing packages only on the first start is a good thing, sure, but the package manager will not warn the user when he after the first usage removes a package that is needed by a YaST module that manages its dependencies in this way. Nor will the package manager tell you that there might be a version conflict if you up- or downgrade a required package that gets incompatible by this. > Testing for missing packages should be optional (e.g. via menu item > or button) in this case. If not required by the package itself (so the user gets a warning if he accidentally or knowingly tries to remove it) it should be default. > Its not technical, its more product management ;-) Ok, so we solved a product management requirement by not using the best technology we have to handle technical requirements ;-) So, I will not change anything for now but I am still of the opinion that we should fix this in the future. Lukas presented a very neat way of solving this. Ciao, Daniel -- J. Daniel Schmidt <[EMAIL PROTECTED]> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
