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.
> 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
zones-discuss mailing list