Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] util-linux: Use u-a for getopt
Date: Fri, 22 Mar 2013 14:06:48 +0100	[thread overview]
Message-ID: <20130322130648.GT3219@jama> (raw)
In-Reply-To: <CAC1BbcRfxRkSDfs5g5eWRoHOQYApR0hhuS=rvW_Ryghv0wO50A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3245 bytes --]

On Fri, Mar 22, 2013 at 12:51:42PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 March 2013 10:15, Martin Jansa <martin.jansa@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@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
getopt provider deterministic in image. default busybox defconfig does
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
from util-linux when util-linux is installed.

> If so, what libc are you using?

private external

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2013-03-22 13:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 15:09 [PATCH] util-linux: Use u-a for getopt Martin Jansa
2013-03-22  8:08 ` Bernhard Reutner-Fischer
2013-03-22  9:15   ` Martin Jansa
2013-03-22 11:51     ` Bernhard Reutner-Fischer
2013-03-22 13:06       ` Martin Jansa [this message]
2013-03-23  8:54         ` Bernhard Reutner-Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130322130648.GT3219@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rep.dot.nop@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox