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-mod...
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