On Wed, Oct 22, 2008 at 09:07:18PM -0700, Danek Duvall wrote: > > Maybe I'm just asking for a few RFEs (smarter column selection, inverse > > dependency listing, help that enumerates possible -t and -o values), > > though. > > Those are all good RFEs (search actually covers the reverse dependencies, > but not at all intuitively), but some ideas on how they might work are > greatly appreciated.
I'm afraid I haven't thought hard enough about it to be able to help much. I can throw out random opinions with the best of them though. > Given that -o values can be absolutely anything, what > should we suggest? -t is much more constrained, but at least those are > completely documented in the man page, and so verbose help seems less > useful. I disagree - one the nicest things about zfs(1) is that you almost never need the man page. Interactive help is so much easier. > As for smarter column listing, what would you suggest? Perhaps we could > have a default column listing for each action type -- "-t depend" could > imply "-o fmri" Yes, please - each -t option should have a default set. > -t link,depend? Default to -m if more than one -t is specified with non-matching default sets, seems like the only sensible way to display disparate objects. The current output looks funny anyway. > Should the default output (no -t option) have all types or just > actions with paths? I think the current choice is the right one. > I'm thinking that perhaps we should have a -l (long) option akin to ls that > gives you a multicolumn output by default, giving similar output to ls for > filesystem objects, and both fmri and type for dependencies, etc. > > And perhaps a -a option that tells it to list all types? Maybe prefixing > each line with the action type? Perhaps -m is really enough. > What about if -t isn't specified, but -o is, then only actions with > attributes named in -o are printed -- so you can do pkg contents -o path. That would be a nice enhancement. I do think that dependencies are worthy of special treatment, however, to the extent of deserving pkg depends and pkg depends-on. regards john _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
