Danek Duvall wrote: > On Mon, Jul 21, 2008 at 02:26:22PM -0700, Brock Pytlik wrote: > > >> Well, here's an example of what a match on a description looks like: >> INDEX ACTION VALUE PACKAGE >> gmake set description pkg:/[EMAIL PROTECTED] >> >> for this action: >> set name=description value="gmake - GNU make" >> > > >> In the first answer, I'd probably prefer that gmake and description were >> switched, but that's not possible without a fair amount of additional code >> to deal with the special case of attributes. If I'm remembering correctly, >> the problem has to do with the issue of what actions' key_attr can be set >> to. The value of key_attr is what currently ends up in column 3 >> (description for some set actions). If this is a serious problem, I can >> look into a way to make the output: >> > > Okay, I see the plumbing issue. I think it'll be okay as it is for this > putback, but I think it's going to be pretty confusing, so you should look > at fixing it pretty quickly. I don't think it'd be hard, though. > Handwaving: > > - add a new method to actions: search_result() or something > - make search_result() in generic actions return the value of key_attr > - make search_result() in set actions return the value of the action's > "value" attribute > - make search_dict() call a.search_result() instead of > a.attrs.get(a.key_attr()). > > If that works, that wouldn't be very much work. But we'll need to change > the plumbing anyway in order to push the entire action down the pipe. I > haven't thought about that problem much, so I don't know whether my hand > waving above aligns with potential solutions in that space. > Actually, it's pretty close to something I'd been toying with, which was to create another attr, called search_attr and use that in place of key_attr. Generically, search_attr would be key_attr, but in attribute, it would be different. Is there a preference between adding another attribute versus adding a function? > It *certainly* wouldn't be hard to make the first column return > "description" there, which might alone be less confusing than the reversal > you currently have. > Actually, I think we really don't want to do this. If we were only doing exact matches, I'd agree. But if I search for a*bd?[fa]*, I'd really like to know what that matched on, so I think returning the matching token somewhere is better than repeating description. > >> And this is what a local search of SUNWgmake returns: >> INDEX ACTION VALUE PACKAGE >> fmri set fmri pkg:/[EMAIL PROTECTED] >> >> for this action: >> set name=fmri value=pkg:/[EMAIL PROTECTED],5.11-0.89:20080527T163123Z >> > > >> I think the second answer is fine, but I'm open to suggestions on how to >> improve it. >> > > I'm not thrilled with it, but I'm not sure of the right answer. Maybe all > set attributes should just return the text of the attribute (i.e., the > value of the action's "value" attribute), at least if they're a single > word. > > I'll admit I'm a bit confused why you'd want to repeat the package name twice. What you're describing is (modulo the space issue) the default behavior for set actions. I could set the first "fmri" to be null (or an empty space) if that's better.
In general, set actions have 4 pieces of information. 1) That it's a set action (column 2) 2) The package the action is in (column 4) 3) The name of the attribute set (column 3) 4) The value of the attribute set (column 1) Sometimes these are duplicates of each other (as in the case above), and in the cases I know them to be duplicates (only the fmri one leaps to mind) I choose to present what I thought was the appropriate information. Thanks, Brock > Danek > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
