Brock Pytlik wrote: > jmr wrote: >> Brock - the first thing we do in the UpdateManager is get the list of >> pkgs and state dic's that describe the packages using >> img_obj.inventory(). As long as the data is available in the state >> dic we can consume it. This would seem to be the right place to add a >> reboot flag (could be an enum if there are a range of values based on >> severity level). >> >> One issue I have at the minute is that the state dic contains an >> incorporated flag which is great but its not updated so not so good. >> If you just add a reboot flag to the state dictionary then we can >> grab that too. This way the GUI's can leverage information coming >> back from the API with minimal change. >> > I don't think this is a viable solution. I don't think I explained > things clearly the first time, so let me try again. A package as a > whole won't cause a reboot, a specific action within that package > will. Whether or not that action is performed will depend on the > version being upgraded from and to. So it doesn't make sense to make a > package as reboot needed before the installation of that package has > been evaluated. Pity - would have been nice to surface this in the UpdateManager GUI. One option would be to do the evaluate in the UMNotifier which runs periodically in the background to check for updates, then cache this data for the UM GUI to consume later on, would reduce startup and allow us to notify the user about these issues. > > Also, encoding a particular implementation of Image.inventory() (or > the implementation of its state dictionary) which escapes past the API > is, imo, the wrong thing to do as its exactly things like this that > have caused problems in the past. That's just a workaround until we get the list of packages directly from the API :) We agreed that this would not happen for the initial release. > > More generally, that solution doesn't solve the problem of "installing > these 6 packages will cause these 9 services to be restarted." The > reason I'm a proponent of option 3 is that it allows us/package > creators to add new services to be restarted without having to > coordinate the change with the clients. When the clients are aware of > specific actuators (I think that's the new term for things that let us > know a reboot is needed, or to restart an smf service, etc...), they > can notice a particular flag and present their UI accordingly. But, > when a new flag is added they're not aware of, they can fall back to > the string and severity level for a generic UI display. > > As a side note, if info is really slow because it's touching the disk, > I can add a brief option, or a no-summaries option, or something like > that so that the manifests (and the summaries) aren't retrieved from > disk. Then the summary and size returned would simply be None. Its the size we want :( Tends to be more relevant for updates for users. > > As for the incorporated flag, I don't have a clue what that is. In the > GUI, is that indicated by the little green star thing? In any case, > I'm not sure what it's purpose is, who's maintaining it, or whether it > should go away. The little green star is just for new updates, there is one for reboot. The incorporations indicate that a package belongs to an incorporation and so if you wish to upgrade that package you have to do an image-update on the incorporation, so it has a big impact on the user. >> One other problem I have at the minute is fetching info objects from >> the api is painfully slow. So for instance I'd like to display the >> size of the packages to upgrade in the treeview, but it takes over a >> second to fetch each info object to get this data from the manifest, >> which is way to slow for us. At the minute I just hide the size >> column and force the user to click on the row to get the details, >> including size . Not ideal but workable atm. What we really need is >> caching support on the client for the info objects and the underlying >> manifest data. Other wise we will end up doing the caching and that >> seems to be broken. >> > I would tend to say that caching information should be handled by the > client according to their needs, since different clients might have > vastly different cacheing protocols and needs, and to force a single > one into the API, or make several available via the API seems the > wrong direction to go to me. I'll admit I'm confused as to exactly > what the problem is. I understand that info is slow since it must > touch the disk to read the manifest, but how was that not the case > before? Doesn't packagemanager currently have to read in each manifest > from disk to get its summary and license anyway? I don't think the API > should replace whatever cacheing system you were using to make that > fast, I think it should replace those times when the package manager > was directly reading the manifest from disk. Well what would be nice would be to have pkg refresh take an optional cache option so it would save off a single cache file of all the manifest data that is in lots of separate files. Then when we have an API to retrieve the inventory and with the existing one to get info objects they could take a boolean option to retrieve it from the cache or directly. That way you hide the details from the clients but make fetching the manifest data a lot faster. Its up to the clients to make sure refresh has been called with the cache option.
If this isn't done we will end up generating a cache file using UMNotifier to do the work and have the client consume it if its available, but then we will have different code paths for consumig the cache or the API info objects :( _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
