|
Bugzilla – Full Text Bug Listing |
| Summary: | SuSEconfig.scrollkeeper takes ages | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Holger Hetterich <hhetter> |
| Component: | GNOME | Assignee: | Karl Eichwalder <ke> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Enhancement | ||
| Priority: | P3 - Medium | CC: | gnome-bugs, ke |
| Version: | Alpha 1 | ||
| Target Milestone: | Alpha 4 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Holger Hetterich
2004-09-08 21:22:25 UTC
<!-- SBZ_reproduce --> install beta1 gnome-only I meant "now running", not "not running" :) Thanks for the report; I will take a look tomorrow. Maybe, bug 59510 is related... On my system (PIII 500, 256 MB RAM) installing scrollkeeper and running the post script takes 3'40'' with heavy disk trashing... There are 2 possibilities to work around this annoyance: 1/ install scrollkeeper before all the other Gnome packages get installed (then SuSEconfig will do the dirty work later). 2/ remove the database initialization from sk's %post alltogether; consequence will be like 1/ . The 3rd possibility would be to improve sk (validate .omf files at packaging time and write the database in 1 pass). But it isn't me who can fix/re-write sk. Please decide what to do. bug 59510 isn't related, I'd say. As an aside, NLD doesn't need scrollkeeper at all anymore. Maybe 9.2 should be going in the same direction? *** Bug 60426 has been marked as a duplicate of this bug. *** We've tried to make it so that scrollkeeper is not needed, but we've done no audit, so we have no idea if that is actually true or not. As an aside, in beta3, 'SuSEconfig --module scrollkeeper' exits almost immediately for me. Am I doing something wrong? I recall something about scrollkeeper trying to go online to get certain DTDs if they're not installed locally, and that process (or some attempted resolution timing out) makes the process much slower. Dunno whether that's still the issue, though, but having the DTDs it's looking for on the local box accounted for it being quite fast for some users and excruciatingly slow for others. * This comment was added by mail. bugzilla-daemon@suse.de writes: | ------- Additional Comments From mtgordon@ximian.com 2004-09-24 23:33 | ------- I recall something about scrollkeeper trying to go online to get | certain DTDs if they're not installed locally, and that process (or some | attempted resolution timing out) makes the process much slower. Dunno | whether that's still the issue, though, but having the DTDs it's looking | for on the local box accounted for it being quite fast for some users | and excruciatingly slow for others. This time, it must be something different. I tried it on a standalone machine and it also took ages (nearly 4 minutes on a PIII/500). If it wouldn't find the local DTDs it would fail completely. My suspicion is, it validates all files again and again while it works on OMF after OMF file. Since I'm not a C hacker I am not able to debug the problem at the source level. last time I installed the 9.2 master on my home machine (P4/2.6) it took about 15 seconds. So I guess the waiting time is tolerable on todays machines. I set this to enhancement, and hope that we find a good solution for this for 9.3 Setting to LATER Still an annoying defect. Reopening... We are hoping to kill scrollkeeper in the next round of development through a series of other fixes. We can just remove scrollkeeper from sel files (and maybe from the CD?) At this point, yelp isn't using scrollkeeper anymore. Thanks - I just filed a drop request (PDB). We must remove scrollkeeper references from all .spec files. So, looking into it more, it looks like scrollkeeper may be a build requirement of lots of tarballs. However, it's only a build dependency. Even packages that build depend on it don't require it at install (it's not in a default SuSE 10.0 install of gnome, for instance.) We could patch the configure files of all these packages, but I don't think it's worth it. I would suggest we just let it live as a build time only dependency (until it's removed from gnome over the next year or two.) Oh. One thing to note is that a default gnome install of SL 10.0 does not include scrollkeeper. I don't see long runtimes with scrollkeeper anymore, so If you ask me, we could resolve this to FIXED and close. Yes, we only have scrollkeeper as a build time dep now. At least on beta6 we also install it with the GNOME selection. And during system installation it is still rather slow. The faster your machine the less obvious the delay ;) For 10.2, we either must get rid of SK completely or fix the this very bug that still exists on 10.1 (GM). I'm going to remove suseconfig.scrollkeeper. Let's see what happens. Packages such as gedit and pybliographer still build; I'll submit the change to STABLE. |