On Wed, Jan 27, 2010 at 10:58:27AM -0600, Shawn Walker wrote:
> On 01/27/10 06:36 AM, Gary Pennington wrote:
> >Hi,
> >
> >(I'm hoping to get these changes in b132 to help on-ips work with zones)
> >
> >Webrev:
> >
> >http://cr.opensolaris.org/~garypen/gate/
> >
> >bash-4.0$ hg comment
> >12738 zone install/attach incorporation logic needs enhancement
> >14053 pkg brand creation potentially broken with new publisher data
> >
> >The change to client.py is probably most controversial. I've introduced
> >a (very simple) parseable output mode for the publisher sub-command so
> >that I can access the information easily when installing zones.
> 
> I believe we have a bug open somewhere that talks about parseable output 
> 'pkg publisher', but d.o.o is down at the moment so I can't see it.
> 

I found:

http://defect.opensolaris.org/bz/show_bug.cgi?id=5775

This isn't related to publisher output.

> >The guiding principles are:
> >
> >  - produce output that standard unix text processing tools can process
> >  - assume that repetition of redundant data to support line-oriented
> >    reporting is fine
> >  - don't print headers when using parseable mode
> >  - assume that "something better" is coming along in the future and this
> >    approach is good enough for now
> 
> I would actually prefer that the -H option be required to omit the 
> header (as it is normally), and that an appropriate header be included 
> by default.  Not only would that make debugging the parsing easier since 
> it would be clear which field is supposed to be which, but it would make 
> it reasonably acceptable to expose to end-users.
> 

Ok.

> ...
> >The changes to common.ksh and pkgcreatezone are less controversial and take
> >advantage of this new output option to fix the two bugs.
> >
> >I'd like to make this change available to everyone using the pkg command,
> >but I would agree if it made more sense to make this option project
> >private and undocumented given the time pressure against the 132 deadline.
> 
> I'm of mixed feelings exposing it to the end user, only because so much 
> has been subject to change.
> 
> However, I think it it is reasonably safe to say that (at this point) 
> that it is unlikely we'll need to significantly alter publishers such 
> that the output of pkg publisher that the parseable output would have to 
> change format (other than perhaps the status field value itself).
> 
> If others agree on exposing this functionality, then please update the 
> usage message and man page.
> 

No-one else has objected, although I will adapt the interface to match
Stephen's request for an additional format specifier. (see other mail)

> Finally, to ensure that this doesn't get broken, please add a unit test 
> to tests/cli/t_pkg_publisher.py that ensures that the output matches 
> what you expect.  For an example of how to compare cli output to a 
> pre-defined expected set of output, see tests/cli/t_pkg_list.py.
> 

I'll do my best to get this done today, but will certainly putback tests
asap.

Thanks,

Gary

> Otherwise, these changes seem reasonable.
> 
> Cheers,
> -- 
> Shawn Walker

-- 
Gary Pennington
Solaris Core OS
Sun Microsystems
[email protected]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to