I've only looked at updatemanager.py, and mostly focused on how it 
interacts with the API.

line 329-300:
You might want to pass a function as the fourth argument to the 
constructor here. The function you provide there will be called whenever 
the cancelable status of the api changes. That would let you, for 
example, flip a cancel button as active or non-active as the back end 
moves through different stages. It's also possible that such 
functionality isn't needed, in which case we'll remove that call back 
function in the future. This might remove the need for you to introduce 
lines like 886 throughout the code and instead rely on the callback 
mechanism.


820: I'm curious why you're installing without refreshing the catalogs 
in the default case.

821-837, 864-880, 888-908:
Unless you're calling out those API exceptions specifically, it might be 
easier to maintain and read if the code looked something like:

                except (api_errors.CanceledException):
                        gobject.idle_add(self.w_progress_dialog.hide)
                        self.__cleanup()                
                        return
                except (api_errors.ApiException), ex:
                        
                        self.install_error = True
                        gobject.idle_add(self.__progress_error_eval)
                        gobject.idle_add(self.__update_progress_info, 
                                self._("\nERROR"), True)
                        gobject.idle_add(self.__update_progress_info, \
                                self._("Update Evaluate failed:\n%s" % ex))
                        self.__cleanup()                 
                        return

849: Probably should either use _extract_names here or get rid of the 
method.

I was surprised that updatemanager is only installing packages, and 
never doing an image-update, but I probably don't have a great 
understanding of the use case for it.

Take care,
Brock


jmr wrote:
> Hi,
>
> Here is a webrev of the first cut of the UpdateManager for OpenSolaris. 
> Its using Brock's new API, including Michal's ProgressTracker changes. 
> It will need refreshed when these other patches land in the gate.
>
> http://cr.opensolaris.org/~jmr/updatemanager_v2_Oct03/
>
> It consists of:
> - service svc:/application/pkg/update, responsible for adding a cron job 
> entry to launch update-refresh.sh periodically (as already discussed on 
> the list, workaround as there is no cron job action in IPS)
> - update-refresh.sh: runs pkg refresh as determined by the cron job entry
> - updatemanagernotifier: a desktop startup application that checks for 
> updates periodically (Daily, Weekly, Monthly) and notifies user in the 
> notification panel by displaying an update available icon. Clicking on 
> the notification icon launches updatemanager
> - updatemanager: updatemanager GUI
>
> There is some pylint work to do, a few changes in updatemanagernotifier 
> and desktop icon to be added for updatemanager, but this will let those 
> interested have a look.
>
> When built SUNWipkg-um is the generated package. To get 
> updatemanagernotifier running requires a reboot. You also need to have 
> SUNWpython-notify installed (coming into b99).
>
> We are targeting this for the 2008.11 release.
>
> JR
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>   

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to