On Mon, Jul 21, 2008 at 04:09:42PM -0700, Brock Pytlik wrote: > 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?
No, an attribute would be fine for now. A function would have the added ability to specify parameters (like "short=True" or something) but until we have a use case, I don't care, and it's all private interface anyway, so we can always change it later. >> 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. Okay. > 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. No, please keep it a parseable four columns for now. The reason I suggested putting the package name is that it would be the full fmri as specified in the action, rather than the "short" version in the last column. But I'm happy to leave it the way it is for now and see what other people end up thinking about it. The opinions of just two people don't really count for much here. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
