On Thu, Apr 29, 2021 at 5:44 PM Andre McCurdy <armccurdy@gmail.com> wrote:

> On Thu, Apr 29, 2021 at 3:29 PM Khem Raj <raj.khem@gmail.com> wrote:
> >
> > On Wed, Apr 28, 2021 at 10:40 AM Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > >
> > > On Tue, Apr 27, 2021 at 10:06 PM Khem Raj <raj.khem@gmail.com> wrote:
> > > >
> > > > certain applets are enabled but the long options are not enabled for
> > > > them, it results in subtle failures in ptests where its expecting
> these
> > > > options e.g. gzip --best is commonly used in many package tests e.g.
> > > >
> > > > root@qemux86-64:/usr/lib# grep -r "\-\-best" *
> > > > acl/ptest/Makefile:GZIP_ENV = --best
> > > > attr/ptest/Makefile:GZIP_ENV = --best
> > > > coreutils/ptest/Makefile:GZIP_ENV = --best
> > > > ethtool/ptest/Makefile:GZIP_ENV = --best
> > > > libxml2/ptest/Makefile:GZIP_ENV = --best
> > > > lttng-tools/ptest/Makefile:GZIP_ENV = --best
> > > > opkg/ptest/Makefile:GZIP_ENV = --best
> > > > perl/ptest/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm:
> COMPRESS     ('gzip --best')
> > > > python3.9/test/test_gzip.py:        for compress_level in ('--fast',
> '--best'):
> > > > ...
> > > >
> > > > this ensures that these options are enabled by default, which makes
> them more
> > > > compatible than now with coreutils provided utilities
> > > >
> > > > busybox size grows by 4K which perhaps is acceptable
> > > >
> > > > --rwxr-xr-x root       root           817704 ./bin/busybox.nosuid
> > > > +-rwxr-xr-x root       root           821800 ./bin/busybox.nosuid
> > > >
> > > > This makes autopoint-3/gettext pass
> > > >
> > > > Signed-off-by: Khem Raj <raj.khem@gmail.com>
> > > > ---
> > > >  meta/recipes-core/busybox/busybox/getopts.cfg | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/meta/recipes-core/busybox/busybox/getopts.cfg
> b/meta/recipes-core/busybox/busybox/getopts.cfg
> > > > index 8db0a4a8f2..aeb5ac691f 100644
> > > > --- a/meta/recipes-core/busybox/busybox/getopts.cfg
> > > > +++ b/meta/recipes-core/busybox/busybox/getopts.cfg
> > > > @@ -1,3 +1,10 @@
> > > >  CONFIG_GETOPT=y
> > > >  CONFIG_LONG_OPTS=y
> > > >  CONFIG_FEATURE_GETOPT_LONG=y
> > > > +CONFIG_FEATURE_GZIP_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_TAR_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_CHOWN_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_CP_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_DIFF_LONG_OPTIONS=y
> > > > +CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS=y
> > >
> > > What's the connection between enabling the getopt applet (a utility to
> > > help with parsing options in shell scripts etc) and enabling support
> > > for long options in a bunch of other unconnected apps?
> > >
> > > I think enabling support for long options in a particular app would be
> > > better done where that app is enabled (e.g.
> > > CONFIG_FEATURE_GZIP_LONG_OPTIONS should be enabled where CONFIG_GZIP
> > > is enabled - in the defconfig file).
> >
> > I experimented a bit more and it seems that these options are tied to
> > the corresponding feature being enabled
> > so they can be enabled in a fragment, unless the feature itself is
> > enabled it will be ignored and disabled. So for
> > disabled features/applets these options are moot. So as such, I think
> > enabling them is a good thing as it will
> > widen the ecompatibility for busibox systems.
>
> OK, so all that's left to do is to move them into their own config
> fragment (since they have nothing to do with the existing getops
> config fragment).


Yeah perhaps a single flagment is good enough

>
>