[OE-core] [PATCH] util-linux: Use u-a for getopt

[Bernhard Reutner-Fischer]

On 22 March 2013 14:06:48 Martin Jansa <martin.jansa at gmail.com> wrote:
> On Fri, Mar 22, 2013 at 12:51:42PM +0100, Bernhard Reutner-Fischer wrote:
> > On 22 March 2013 10:15, Martin Jansa <martin.jansa at gmail.com> wrote:
> > > On Fri, Mar 22, 2013 at 09:08:34AM +0100, Bernhard Reutner-Fischer wrote:
> > >> On 20 March 2013 16:09:10 Martin Jansa <martin.jansa at gmail.com> wrote:
> > >> > * when enable busybox installs getopt to ${base_bindir} and
> > >> >   util-linux to ${bindir}, so there is no file conflict, but
> > >> >   because busybox implementation does not support --long used
> > >>
> > >> Do you mean that Busybox' getopt does not support long options?
> > >> If so, enable FEATURE_GETOPT_LONG in busybox instead of this patch?
> > >
> > > Having lsb working correctly even when someone has bad busybox defconfig
> > > is right thing to do, isn't it?
> >
> > Probably. That aside, --long being rejected smells like a bug.
> > >
> > > busybox's getopt supports --longoptions, but util-linux's also supports
> > > --long alias for that and that's what lsb is using
> > >
> > > $ getopt --longoptions
> > > getopt: option '--longoptions' requires an argument
> > > Try `getopt --help' for more information.
> > > $ getopt --long
> > > getopt: option '--longoptions' requires an argument
> > > Try `getopt --help' for more information.
> > >
> > > busybox (IIRC even with FEATURE_GETOPT_LONG enabled) reports
> > > getopt: unrecognized option '--long'
> > > BusyBox v1.20.2 (2013-03-16 17:45:30 PDT) multi-call binary.
> >
> > That's odd, it seems to work for me?
> > $ grep GETOPT .config
> > CONFIG_GETOPT=y
> > CONFIG_FEATURE_GETOPT_LONG=y
> > CONFIG_ASH_GETOPTS=y
> > $ ./busybox getopt --long 2>&1 | head -n2
> > getopt: option '--longoptions' requires an argument
> > BusyBox v1.22.0.git (2013-03-22 11:20:17 CET) multi-call binary.
>
> FWIW I have older version (from danny), but the same problem about not
> using u-a is with master.
>
> > > lsb already RDEPENDS on util-linux, changing lsb to use --longoptions
> > > would be good, but having /bin/getopt and /usr/bin/getopt without u-a
> > > to select preferred one is bad, that's why I used this solution instead.
> >
> > Yes, i see what you mean. Still,
> > a) it should not be required for lsb to RDEPEND on util-linux since
> >    busybox supposedly should work fine too, iff configured correctly, 
> of course.
>
> Yes but I'm not changing that in this commit :) All I want is to make

Yep, OK. :)

> getopt provider deterministic in image. default busybox defconfig does

It should be deterministic, agree.

> not have GETOPT enabled at all:
> meta/recipes-core/busybox/busybox-1.20.2/defconfig:# CONFIG_GETOPT is not set
> meta/recipes-core/busybox/busybox-1.20.2/defconfig:# 
> CONFIG_FEATURE_GETOPT_LONG is not set


>
> so if someone wants to remove util-linux from lsb RDEPENDS, then he
> should also update default config.
>
> > b) busybox's getopt --lo (or other substrings of the
> > -l,--longoptions=LOPT[,...] opt)
> >    should work correctly.
> >
> > I'd like to know why you trip b) above.
> > Do you have CONFIG_FEATURE_GETOPT_LONG set?
>
> I've rechecked and CONFIG_FEATURE_GETOPT_LONG is not set, only
> CONFIG_GETOPT is. But this commit is still valid, I want to use getopt

Given how "fat" any OE distro (except micro) is,  I would strongly 
suggest to turn on FEATURE_GETOPT_LONG anyway.

That is of course not relevant for this very patch of yours, just a 
general remark.
Cheers,

> from util-linux when util-linux is installed.
>
> > If so, what libc are you using?
>
> private external
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com


Sent with AquaMail for Android
http://www.aqua-mail.com