AW: 'tr' character class support?

[Magnus Kroken]

Hi

On 11.07.2020 09:18, Thomas Endt wrote:
>> --- Config-defaults.in.orig     Fri Jul 10 21:03:57 2020
>> +++ Config-defaults.in  Fri Jul 10 21:03:22 2020
>> @@ -837,7 +837,7 @@
>>           default y
>>    config BUSYBOX_DEFAULT_FEATURE_TR_CLASSES
>>           bool
>> -       default n
>> +       default y
>>    config BUSYBOX_DEFAULT_FEATURE_TR_EQUIV
>>           bool
>>           default n
> 
> What impact on busybox package size does this have?
> 

I did a comparison, which gave about a 500 byte increase to the 
compressed package:

r13779+11-9362ea1661

Default config:
-rw-r--r-- 1 openwrt openwrt 208372 Jul 11 13:54 
bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk

With CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y
-rw-r--r-- 1 openwrt openwrt 208868 Jul 11 14:06 
bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk

With CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y and 
CONFIG_BUSYBOX_CONFIG_FEATURE_TR_EQUIV=y
-rw-r--r-- 1 openwrt openwrt 208895 Jul 11 14:08 
bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk

For the record, a POSIX compliant tr requires both 
CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y and 
CONFIG_BUSYBOX_CONFIG_FEATURE_TR_EQUIV=y.

I'd say that difference is acceptable, but for similar issues in the 
future there remains the question of how desirable POSIX compliance is 
in OpenWrt, and what sacrifices are reasonable to achieve it. Is there a 
decision, goalr or mindset on this? I'm not a 4/32 fanatic and accept 
that minimum requirements will increase over time, but I still value the 
flexibility of OpenWrt (such as the ability to run on relatively small 
devices). Making tr compliant when it's there anyway and has this small 
cost is good. OTOH, a proper POSIX system requires e.g. a working C 
compiler, which I think is an absurd minimum to set for OpenWrt given 
how useful and flexible it is in its current state.

Regards,
Magnus Kroken