Brock Pytlik wrote: > Shawn Walker wrote: >> Brock Pytlik wrote: >>> Here's the CR: >>> http://cr.opensolaris.org/~bpytlik/ips-bug-2989-v1/ >>> >>> and the bug: >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=2989 >>> >>> The idea is that if indexing fails for any reason during install, >>> image-update, or uninstall, we attempt to reindex from scratch. This >>> will at least hide the KeyErrors and other issues from the users >>> until we can fix the root cause of those problems. >> client.py: >> line 140: you added space to the end of the line here >> > fixed >> lines 575-586: As I understand the localization process, you can't >> take one localized and blindly append it to another localized string >> (mid-sentence, especially) and get a reliable result due to >> subject-verb-order, etc. I'd recommend either passing the full string >> for each case to _() or dynamically constructing the strong *first* >> before passing it to _() at line 586. >> > Ok, will what I have now work?
What you responded to Danek with should work fine. It's ok to dynamically construct a string as long as you pass the full string to _() -- not pieces of it. >> I also wonder what impact this will have on the GUI, etc. Should the >> re-index logic you added to client.py be a shared method in one of the >> search modules that can be called by the GUI or client.py as needed >> instead of solely being in client.py? > The try_index_again can live anywhere that the client can get to it. To > answer you and Danek's question, I put it up at the client level because > it prints a message to the user. If it's preferred, I can move > everything down into imageplan and remove the user message. The reason I > didn't want to do this is because it would completely hide the fact > that there was a problem, which means we'd never know when the indexes > and installed packages were out of sync. If that's the route we're > going, then I'd tend to say the right thing to do is simply rebuild the > index from scratch every time rather than trying to keep it in sync and > minimize update times. Without feedback from errors, we won't have a way > to tell if/when we've gotten out of sync because the users won't notice > anything other than indexing taking longer than it maybe should. > > Thoughts? This seems like something we should be able to figure out on our own. We should have some way of "knowing" (by an image attribute or a file timestamp?) that the index needs to be synchronized. The user shouldn't have to run a special command to update the search indexes -- it should just "do the right thing." The only exception I can think of to this case is where you are performing a search and it is determined that the search index can't be updated due to some unforeseen reason (readonly filesystem, permissions, etc.). In general, I'd prefer to avoid any such messages. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
