Bart Smaalders wrote: > Darren Kenny wrote: >> [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. >> > > I have this working in prototype form right now; any action can have a > refresh_frmi or restart_fmri attribute; when that action is installed, > uninstalled, > or modified the specified service is either refreshed or restarted. > Multiple refresh/restarts > of the same service are of course coalesced.
Excellent! Any idea when this might be integrated? > >> 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... > > As above. Note that when updating packages, only those actions which have > changed are modified; and when updating multiple packages, the changes are > merged together and performed as a single update. All > refreshes/restarts happen > after all other actions have been updated. Sound perfect. So how is it intended that packages would include the necessary information for IPS to be able to know what to do? As I understand it, installing a single file is an action - so it would be at this level that you might include the restart_frmi or refresh_frmi - is that correct? So if we are building SVR5 packages and sending them to the repository, how is this information to be included - for example while a given file (e.g. icon or font) might require a cache refresh, others might not - how granular is this able to be defined? >> 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. >> > > Note that this software also has to work correctly when installing bits > to a > image which isn't booted. One of the fundamental design constraints we're > placing on IPS is that it be able to manipulate images regardless of version > skew between the live image and the image being manipulated. Indeed, it > needs to be possible to create bootable SPARC images when running on an > x86 machine. This forces us to make a clean separation between installation > and self/auto configuration; we simply do not run any portions of the > software > being installed during packaging installation. Sure, totally understand that you might be installing to an image that is not booted - I wouldn't expect the "installer" to be run then, but I don't think that enough to just not have anything. In the Debian world there is something called debconf to provide a simple UI (text, curses, GNOME, KDE, etc). to the user. Each dpkg can use this to define various configuration options, and this then allows that user to be presented with a UI that meets their needs (depending on debconf's own configuration). I think that something like this would be useful for us to have, and while I think it's not IPS that does the configuration, it would need to be able to trigger it in the right circumstances. Thanks, Darren. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
