* Darren Kenny <[EMAIL PROTECTED]> [2008-05-15 16:59]: > [Apologies if I'm coming in on this with some information lacking] > > A specific couple of cases that I'd like to be sure are being addressed: > > 1) Installing a single desktop application > > In this case, I certainly would like to avoid the need to reboot to > ensure correct operation - that would be going backwards - but it's > a matter of fact that right now, and it's unlikely to easily > change, that when you install new icons/fonts/.desktop files, etc > with GNOME you need to update a cache - doing this solely using SMF > would mean that the user might not be able to get correct operation > of the newly installed application until after a reboot, when the > SMF service is restarted. > > At a minimum, I think we would need some way to trigger an SMF service > refresh after a package has been installed - in a previous e-mail I > think I saw that this mechanism is being considered already, and if it > worked as expected then I'd be happy that we'd not need to reboot just > to see the new app working, but it would be good to confirm that I'm > correct in this assumption. Yes, that's the plan. No reboot will be required (unless the package says a reboot is needed).
> 2) Multiple installations that have the same effect chewing CPU, etc. > > In this case, we have several applications as in (1) above, installing > fonts/icons, etc. If we were to trigger an refresh at each package install > then > we would end up updating the caches several times rather than doing just one > update at the end. > > >From what I understand this might not be an issue since the installation of > >such > a group of packages is done in a single transaction, and then the refresh of > the > SMF service would be done, but I'd like to be sure... Yes, the refreshes/restarts would only happen at the end of the transaction, not for each package within a transaction. Actually, the current thought is that the refresh would only take place if a file of the particular kind is updated during the operation. If 1.0 and 1.1 of a package both deliver cached file X, then the cache won't need to be updated. > 3) More complex configuration needed > > Is there some thought been done to the provision of a mechanism to > trigger a more complex guided configuration tool - e.g. in > apt-get/dpkg it's a package knowns how to configure itself - in > some cases this is minor, but in other's it might pop-up a UI to > configure the application and complete the install - if a desktop > is running. > > I think something like this wouldn't fit too well into SMF, but it > might be useful to be able to auto-launch such things if installing > using Package Manager. > > While I understand that some people think that this should be a custom > installer which runs first, and then installs the packages - having it > run the other way around is much more useful for s/w that is sourced > from a package repository. > > A common use-case of this, that I've seen used on the Maemo platform, > is that after you install an application, it prompts you to decide on > where you would like it to appear in the menus. I think, if Michal's interested, we could put metadata that offers an application to run post-installation, so that packagemanager could launch it. We don't want that to be required for correct delivery of a package, and we wouldn't want the CLI to launch that application. It could mention the application in a message, however. For system wide package operations, however, the notion of who should run a specific configuration helper isn't always clear. > Another use-case would be in the case of a conflict during > installation/merging of a configuration file - do we always overwrite, > or not, or could we prompt the user for a decision - again something > I've seen apt-get do. The package author decides whether a file is updated, preserved, etc. We don't want to prompt here. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
