On Thu, Jun 19, 2008 at 7:35 AM, Jerry Jelinek <[EMAIL PROTECTED]> wrote: > Mike Gerdts wrote: >> >> The only reason I would say not to use another option is to keep the >> option free for other things in the future. > > Mike, > > Saving the option is not such a big concern. This option > would be brand-specific and as such, would not have to be > carried forward to other brands.
And the more that I thought about it, I realized that an IDR is more likely that most patches to be the source of a large dependency tree of patches that are incompatible. As such the ability to specify a file containing a list would be a good thing, assuming this approach is taken. My big concern here is that if the zone is attached with incompatible patches, the patching utilities will impose restrictions that prevent me from ever fixing it. I'm not sure how you support such a zone in the long run. I would much prefer that the incompatible IDR is backed out. Then, if it is still relevant, I can chase down an updated IDR that fixes the issue in the zone. My guess is that if it is something that is still relevant the replacement IDR is already installed in the global zone. My experience is that I've needed very few (one, I think) application-specific IDR's - most tend to update the kernel or a driver. The one purely user space IDR that I can think of (ssh -q vs. banner) was fixed in the next release of the standard patch for that package. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
