Brock Pytlik wrote: > Dave Miner wrote: >> [EMAIL PROTECTED] wrote: >>> Hi Brock, >>> >>>> For pkg install: >>>> 1) If a fmri with the version including the timestamp is given, no >>>> catalog refresh will be done. >>>> >>>> 2) Else: If the fmri specifies an authority or the package was >>>> previously installed from a specific authority, then that >>>> authority's catalog will be refreshed, but no others will. If that >>>> authority is unavailable, installation will fail. >>>> >>>> 3) Else: The catalogs for the preferred authority and the authority >>>> the package was previously installed from will be refreshed. If >>>> neither authority is available, the install will fail. If at least >>>> one of the authorities is available, then installation will proceed. >>> It might be worthwhile to start with a simpler approach first, and then >>> make this more complex, as necessary. I might save the time of the last >>> refresh in the catalog attributes and then refresh all catalogs if we >>> haven't refreshed in N minutes. >>> >>> For install operations, it might also make sense to add a command-line >>> flag that will perform the install without refreshing the catalogs. If >>> we already have the manifest for a package, we might have its content in >>> the cache. If that's the case, we can perform the install without ever >>> having to hit the network. I'm assuming that this option won't get used >>> very much, though. >>> >> In particular, I'd like to ensure that bulk operations such as those >> done by an installer or distro constructor aren't going to be >> unnecessarily slowed by automatic refresh. >> >> Dave > Ok, I'll add an option flag to all this behavior to be turned off. Out > of curiosity, is there a reason those might choose to do "pkg install X" > "pkg install Y" "pkg install Z" etc... instead of "pkg install X Y Z"? >
Most of the distribution construction is done using the slim_install cluster, but there are certain packages which must be installed separately and in a defined order (SUNWcs, SUNWcsd) because of the way actions are ordered. In the case of, say, automated installation using a user-defined package list, we might also opt for the individual invocations for the same reason, since we can't tell a priori whether the listed packages would be affected by similar problems. Dave _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
