Stephen Hahn wrote:
> * Joe Di Pol <[EMAIL PROTECTED]> [2007-11-19 21:46]:
>>
>> [EMAIL PROTECTED] wrote:
>>> What would be the benefit of doing this? I'm assuming that you're
>>> trying to say:
>>>
>>> arch > 386
>> The example was meant to be illustrative only. I wanted to confirm
>> that the current restriction on filter values was a bug, and I was
>> curious what additional capabilities were under consideration for
>> filtering.
>
> I don't agree that what you asked about results in "a bug". What
> specific operation or characteristic do you want to filter on?
The fact that
pkg install -f foobar=10 testpkg
Generates this:
Traceback (most recent call last):
File "/bin/pkg", line 669, in ?
ret = main_func()
File "/bin/pkg", line 634, in main_func
install(img, pargs)
File "/bin/pkg", line 203, in install
ip = imageplan.ImagePlan(img, filters = filters)
File "/usr/lib/python2.4/vendor-packages/pkg/client/imageplan.py", line 77,
in __init__
self.filters = [ compile_filter(f) for f in filters + ifilters ]
File "/usr/lib/python2.4/vendor-packages/pkg/client/filter.py", line 49, in
compile_filter
raise RuntimeError, \
RuntimeError: '10' is not an allowable token ('NAME',)
looks like a bug to me.
> (Machine capabilities are not an orderable sequence, so ">" and "<"
> are not sensible for that example.)
True - I never meant to imply they were. The intent was to show that "i386" as
a filter value happens to work today, but "386" does not because the filter
tokenizer chokes on numeric values.
Then I asked a general question if any other operators were under consideration
for filters.
Joe (wishing he had used "foobar" instead of "arch" the first time around)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
