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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
