Enda:
I had seen this done before for updates releases. However, we will
need a Zones developer to see which packages are suitable for the
purpose in an update release. We also need to know which S10 update
releases they are target for. If this is done after the real zone
upgrade support is integrated, it should not be a problem. Both upgrade
and without zones should work.
This is what we know about SUNWcnetr and SUNWipfr:
SUNWcnetr - This belongs to SUNWCcs Product cluster and it is something
that is required and cannot be deselected. It can be installed in
SUNWCrnet, SUNWCreq, SUNWCuser, SUNWCall and SUNWCXall.
SUNWipfr - This belongs to SUNWCipf product cluster.It can be installed
in SUNWCrnet, SUNWCreq, SUNWCuser, SUNWCall and SUNWCXall.
As long as the contents is moved to a root package that is also in
SUNWCmreq and had the proper SUNW_PKG_HOLLOW property, then you can
fine. You will need to find something where SUNW_PKGTYPE=root and
SUNW_PKG_HOLLOW=false and it also needs to be in SUNWCrnet cluster.
Enda O'Connor ( Sun Micro Systems Ireland) wrote:
> Erik Nordmark wrote:
>
>>
>> The IP Instances part of Crossbow will need to make all of the content
>> in the SUNWcnetr and SUNWipfr packages available in the non-global zones.
>>
>> One possible way to do that is to change the SUNW_PKG_HOLLOW attribute
>> for those packages.
>> Another possible way would be to move all those files to some other
>> packages that are not hollow (and effectively leave the above packages
>> as empty.)
>>
>> Given that this is targeting a Solaris 10 update, what is the least
>> painful and most correct way to handle this?
>>
>> Erik
>> _______________________________________________
>> install-discuss mailing list
>> install-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/install-discuss
>
>
> Hi
> It is not possible to change the HOLLOW attribute without changing the
> version, and that would lead to sustaining problems for the release, it
> two sets of patches for the two sets of packages.
>
> The second option is probably more feasible, ie move the files to a new
> package, but I suspect this might be problematic for upgrade in some
> scenario's. but it appears to be the only option as such.
>
> I've cc'ed Mary as she is familiar with upgrade and might wish to comment.
>
> Enda
--
-------------------------------------------------------------------
_/_/_/ _/ _/ _/ _/ Mary Ding
_/ _/ _/ _/_/ _/ Member of Technical Staff
_/_/_/ _/ _/ _/ _/ _/ UMPK17-307
_/ _/ _/ _/ _/_/ Menlo Park, CA. 94043
_/_/_/ _/_/_/ _/ _/ mary.ding at Eng.Sun.COM
650-786-8317 (phone)
M I C R O S Y S T E M S
--------------------------------------------------------------------
