Stephen Hahn wrote: > * 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). >
OK, so Bart mentioned that we would have restart_fmri and refresh_fmri, so is there a reboot_needed attribute too? >> 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. That sounds good, in my reply to Bart I asked about the granularity, I think you've just stated that it would be at the file level. So my next question to Bart was how one might be able to define this in a SVR4 package that is being uploaded... Or are we going to start omitting that SVR4 -> IPS translation step at some point and going to have to generate IPS packages during builds? > >> 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. I mentioned in my response to Bart about debconf, and the need for a trigger - metadata might be enough to trigger it for Package Manager, but not for the CLI. One thing I like about debconf is that it's a consistent l&f when it's needed - CLI from the CLI, GNOME from GNOME, KDE from KDE, etc. While I think it probably not a priority right now, it would be good to have some thoughts outlined on how resolve the configuration element of an install. > >> 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. Fair enough. Thanks, Darren. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
