sorry for the delay in replying. comments below.
On Thu, Feb 17, 2011 at 11:15:19AM +1300, Tim Foster wrote:
> On Wed, 2011-02-16 at 09:21 -0700, Mark J. Nelson wrote:
> > On 02/15/11 08:52 PM, Tim Foster wrote:
> > > SUNW_PKG_HOLLOW
> > >
> > FWIW, I think this translates as "we need the pkginfo to be present so
> > that package dependencies can be met in the nonglobal zones, but we
> > don't want the actual software installed there." That would translate
> > literally as "global zone variant tags on everything except for the
> > legacy actions."
>
> Right,
>
this sounds correct.
> > A more generous (and appropriate, I think) approach would be the
> > "global_zone_only_component" transform set in OS/Net, which allows
> > header files, manpages, and mdb modules from such packages to be in
> > nonglobal zones.
>
> So users could certainly use pkgmogrify to apply such transforms after
> running 'pkgsend generate'.
>
> The 'svr4convert' prototype had a built-in pkgmogrify step and shipped a
> set of standard transforms, but the feeling I got was that it was better
> to separate pkgsend and pkgmogrify responsibilities (hence this webrev)
>
> One good suggestion Bart had on IRC last night was to tag the package
> with a pkg.send.convert.sunw-pkg-hollow attribute if the actions had
> been generated from an SVR4 package that had SUNW_PKG_HOLLOW set,
> leaving the decision to the user on how they'd like to further transform
> the package, if at all.
>
if a package is truly hollow, then it delivers no content so in an ideal
world the package itself would be tagged with a global variant, there by
making it uninstallable within non-global zones, and if any other
packages had dependencies upon that package those dependencies would
have to have variant tags as well. (similarly to how architecture
specific packages are handled.)
but given the non-ideal world we live in (and the approximations we
make when converting packages) i think it's best to leave the package as
installable with a legacy action as you proposed.
> An alternative approach would be to punt on the problem for now, and
> have a follow-on putback automatically add appropriate
> 'pkg.linked.attribute.*' attributes to packages that came from SVR4
> packages with SUNW_PKG_HOLLOW or SUNW_PKG_ALLZONES - though I'm not sure
> yet how well this maps onto the linked-image work. Ed?
>
with linked images we gain a new property that is similar to
SUNW_PKG_ALLZONES. see at "pkg(5) linked image manifest metadata" (line
1080) in:
http://cr.opensolaris.org/~edp/pkg-li.20110216.0/doc/linked-images.txt.html
basically, if SUNW_PKG_ALLZONES is set that means we should generate the
following package attribute:
set name=pkg.linked.attribute.zone-sync value=true
ideally, we should also automatically add this property (and variant
tags) to any package which delivers a kernel driver/component.
that said, i'd prefer that we delay adding this attribute to the svr4
conversion process until after linked images integrates and we've
started setting this property ourselves within the WOS. (since then
we'll have the exact mechanics of when this attribute is set ironed
out.)
also a question, when you convert more than one svr4 package to an ips
package, do you create an incorporation which ties together the packages
your converting? (i ask because if you do, then we'll may optionally
want to set the attribute on the incorporation if it's set on any
packages incorporated by the incorporation. this question goes back to
the mechanics of when this property gets set. :)
> > This begs the question "should that transform set also set
> > variant.opensolaris.zone=__NODEFAULT on legacy actions?"
>
> I think it should.
>
agreed.
ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
