I've been thinking about some of the issues raised here. Because of the cross-authority issues raised, I think a different approach may be called for.
So, here's version 2: 1) Anytime set-authority is called, we refresh that new or changed authority. (That part seemed uncontroversial the first time around.) 2) The general approach will be, we'll refresh all the catalogs, if that's not what you want, it's possible to work around the problem. i) pkg refresh will be able to have specific authorities given so that the user can refresh specific catalogs. ii) pkg install, image-update will have an option (-d?) which takes an argument and means don't automatically refresh the authority provided. We could also provide an option (--dall?) which means don't refresh any authorities. iii) pkg install, image-update, if -d isn't given, will attempt to refresh all known catalogs. If it can't refresh any catalogs, the operation will fail explaining that it can't contact any of the authorities (which means it probably won't be able to get any new packages from them either). If it can reach at least one authority, it will try to continue with the update, but if package comes from an unreachable authority, it will fail, politely explaining what the problem is. I think this covers all the problematic areas. It does the right thing (refreshing all catalogs) in the default case. Users concerned with the bandwidth of catalog updates can use pkg refresh to refresh specific catalogs and the -d option to specify which catalogs should not be refreshed. Installers can use the -dall option to ensure that no catalogs are ever updated. Users with some depots offline, a local depot for example, can use the -d option to specify that depot on the command line. How does this strike people? Thanks, Brock [EMAIL PROTECTED] wrote: > Hi Brock, > > >> One problem this is trying to solve is the situation where one (or more) >> of your authorities is offline, but not actually needed for the >> install/update that's being attempted. For example, the packages ares >> coming from repo Y, but you also have repo Z as an authority, but Z is >> down. It would be nice if image-update proceeded (which it doesn't >> today) and if install did not try to refresh the catalog from Z and then >> die. >> > > I hadn't considered this case, although I suppose it might be covered by > a don't-bother-to-refresh-flag. What do you do in the case where the > user requests package A that is installed from repo 1, but it depends > upon package Q that is installed from repo 7? Are you going to perform > a second refresh after dependency evaluation? It seems like it would be > possible to be arbitrarily complicated with our evaluation, if we so > desired. It might be simpler to just refresh as many catalogs as > possible the first time around. > > >> I'm not sure what the advantage of the N minutes approach is other than >> its simplicity. Do you think the above approach is wrong, or just >> needlessly complex? >> > > I don't think your approach is wrong, but it may need further > refinement. If we have dependencies that cross authority boundaries, > the algorithm below may not refresh all the catalogs that need to be > refreshed. I'm also concerned that we might end up doing more work > than we need to, just to come to a relatively simple conclusion. > > >>>> 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. >>>> > > 4) In the case where the package has never been installed before, and no > authority is specified in the FMRI, do we just refresh the preferred > authority? > Yep > -j > > > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
