|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST should only re-evaluate settings if necessary. | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Volker Kuhlmann <bugz57> |
| Component: | Installation | Assignee: | Jiri Srain <jsrain> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Stanislav Visnovsky <visnov> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | suse-beta |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | https://fate.suse.com/300681 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Volker Kuhlmann
2006-06-14 11:15:42 UTC
I think there was an enhancement request some time ago about that. Of course I agree here. AFAIK keyboard layout should not cause the recalculation if packages. Jiri? No, it definitely shouldn't. IIRC we have a flag indicating if the language changed in the proposal API for just this purpose. A language change does have to trigger reevaluation of packages (translation packages, fonts, input methods), but neither time zone nor keyboard. The problem is that proposal modules are independent. They don't have information which module was changed before, and even if they new it, they don't know which module changes which settings (especially with the add-on product concept, which can bring 3rd-party modules even to the installation proposal). Even keyboard layout change may cause the need of package recalculation - AFAIK there are special packages needed for CJK input, which may get selected by the keyboard module and then software module needs to check available disk space. OTOH I fully agree that package recalculation needs a lot of optimalizations, which I are on my TODO list for 10.2. Stefan: > IIRC we have a flag indicating if the language changed in the proposal API ... this flag is not changed for keyboard nor for timezone, but it doesn't help packagemanager to not do the proposal again. Jiri: > Even keyboard layout change may cause ... Theoretically yes, but this is not implemented anywhere > The problem is that proposal modules are independent. It might have a sense to have a white-list of proposal clients about which we know that recalculation is not necessary. Stano, something for Post CODE10 Clean up... @#5: We could handle it in inst_proposal.ycp. Each client would be able to return special value from the AskUser function, which would mean that settings of the particular module were changed, but that they do not influence any other module. This is IMO safer way than having one universal whitelist... SUSE has always (since 6.x or so) had this problem of re-evaluating everything, and in some cases, re-evaluation is needed to change package selection. But before it was slow on a PIII-450MHz box, now it's bordering on unbearable on a 3.2GHz AMD64 - speed must have dropped by a factor of >10, that's why I made a new bug for it. As changing the language (to en_NZ if there is one, en_GB otherwise) also changes the keyboard, I need to change the keyboard back to US - one of those evaluations is definitely not needed. Would it make sense to defer package re-evaluation until a click on some "check settings now", or even "next"? Of course better would be if you did find some intelligent way of making sure only necessary re-evaluations take place (e.g. modem, ISDN etc should not be needed when changing keyboard, or time zone). And you did notice that the package re-evaluation now unconditionally happens twice in a row? This is a new bug with 10.1, or at least I didn't notice it before, and it almost doubles the time needed. |