[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. 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... 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. 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. Thanks, Darren. Dan Price wrote: > On Wed 14 May 2008 at 06:09PM, Danek Duvall wrote: >> On the other hand, if you're not installing on a live root, then there's >> simply no way to check if the deployment worked until you've rebooted. Any >> solution you come up with *has* to deal with that scenario, and really >> needs to have the same architecture as the live-root case, though we may be >> able to provide some shortcuts for live-root. > > I certainly think there is substantial opportunity to make the > live-root case feel seamless and fairly unified, even if on the > inside, there is a strict (really, really strict) separation between > the two phases: first install, then after-install. With the advent > of ZFS snapshotting, we can offer rollback if something goes really > wrong. And we might be able to offer some sort of developer > productivity measures and additional observability for the post-install > phase. > > With zones the problem is perhaps even more complex-- what if > you do a 'pkg install' from the global zone into a zone, but the zone is > running? > > -dp > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
