Patchwork less: build after busybox

login
register
mail settings
Submitter Gustavo Zacarias
Date July 26, 2012, 7:18 p.m.
Message ID <1343330317-24730-1-git-send-email-gustavo@zacarias.com.ar>
Download mbox | patch
Permalink /patch/173477/
State Accepted
Headers show

Comments

Gustavo Zacarias - July 26, 2012, 7:18 p.m.
Build less after busybox if it's enabled, since we prefer the full-blown
version over the light one if it's enabled (and busybox would overwrite
the link when built afterwards).

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/less/less.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Samuel Martin - July 26, 2012, 10:30 p.m.
2012/7/26 Gustavo Zacarias <gustavo@zacarias.com.ar>:
> Build less after busybox if it's enabled, since we prefer the full-blown
> version over the light one if it's enabled (and busybox would overwrite
> the link when built afterwards).
>
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/less/less.mk |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/package/less/less.mk b/package/less/less.mk
> index b758e46..c0ecf20 100644
> --- a/package/less/less.mk
> +++ b/package/less/less.mk
> @@ -6,7 +6,8 @@
>
>  LESS_VERSION = 444
>  LESS_SITE = http://www.greenwoodsoftware.com/less
> -LESS_DEPENDENCIES = ncurses
> +# Build after busybox, full-blown is better
> +LESS_DEPENDENCIES = ncurses $(if $(BR2_PACKAGE_BUSYBOX),busybox)
Though I understand why you prefer this one, I somehow don't really
like it... because it's not about build dependency, but build/install
order...

At least it would be worth to document which binary works if using the
one provided by the busybox built instead of the one provided by
another package, which doesn't.
This makes echo to some other recent thread about using login from
util-linux or busybox.


Regards,
Gustavo Zacarias - July 26, 2012, 11:12 p.m.
On 07/26/12 19:30, Samuel Martin wrote:

> Though I understand why you prefer this one, I somehow don't really
> like it... because it's not about build dependency, but build/install
> order...
> 
> At least it would be worth to document which binary works if using the
> one provided by the busybox built instead of the one provided by
> another package, which doesn't.
> This makes echo to some other recent thread about using login from
> util-linux or busybox.
> 
> 
> Regards,

It's pretty much standard issue in buildroot for busybox command
alternatives that are richer in functionality when they're selected.
If less is in the configuration it's because someone wants it, specially
since it's hidden by the BUSYBOX_SHOW_OTHERS kludge to avoid
big/duplicate alternatives.
Just hit this particular one when testing the ncurses bump, got busybox
less which doesn't use it even though i selected standalone less.
Maybe i don't understand what you mean about build dependency, but it's
the only way at the moment to ensure it's built after busybox in a
simple way.
And it's been done for a ton of other packages already like iproute2,
gawk, grep, sysklogd, usbutils and so on...
Granted that util-linux might have a heavier hand since the options
aren't so granular and there are several binaries with differing
functionality that overlap busybox, but it's a completely different case
than this.
Regards.
Samuel Martin - July 26, 2012, 11:23 p.m.
2012/7/27 Gustavo Zacarias <gustavo@zacarias.com.ar>:
> On 07/26/12 19:30, Samuel Martin wrote:
>
>> Though I understand why you prefer this one, I somehow don't really
>> like it... because it's not about build dependency, but build/install
>> order...
>>
>> At least it would be worth to document which binary works if using the
>> one provided by the busybox built instead of the one provided by
>> another package, which doesn't.
>> This makes echo to some other recent thread about using login from
>> util-linux or busybox.
>>
>>
>> Regards,
>
> It's pretty much standard issue in buildroot for busybox command
> alternatives that are richer in functionality when they're selected.
> If less is in the configuration it's because someone wants it, specially
> since it's hidden by the BUSYBOX_SHOW_OTHERS kludge to avoid
> big/duplicate alternatives.
> Just hit this particular one when testing the ncurses bump, got busybox
> less which doesn't use it even though i selected standalone less.
> Maybe i don't understand what you mean about build dependency, but it's
> the only way at the moment to ensure it's built after busybox in a
> simple way.
> And it's been done for a ton of other packages already like iproute2,
> gawk, grep, sysklogd, usbutils and so on...
Fair enough.

> Granted that util-linux might have a heavier hand since the options
> aren't so granular and there are several binaries with differing
> functionality that overlap busybox, but it's a completely different case
> than this.
> Regards.
>
Arnout Vandecappelle - July 27, 2012, 8:15 a.m.
On 07/27/12 00:30, Samuel Martin wrote:
>> >  +# Build after busybox, full-blown is better
>> >  +LESS_DEPENDENCIES = ncurses $(if $(BR2_PACKAGE_BUSYBOX),busybox)
> Though I understand why you prefer this one, I somehow don't really
> like it... because it's not about build dependency, but build/install
> order...

  I also don't really like it.  For instance, if you rebuild busybox, this
will not trigger a reinstall of less so it will again be the busybox version
that prevails...

  However, I don't see a better solution than this one.  For sure,
selecting less and getting busybox is worse than this.


  One alternative could be to automatically deselect less from busybox
when the full-blown less is selected.  But also that is a bit complex
I think.


  Regards,
  Arnout
Gustavo Zacarias - July 27, 2012, 10:26 a.m.
On 07/27/12 05:15, Arnout Vandecappelle wrote:

>  One alternative could be to automatically deselect less from busybox
> when the full-blown less is selected.  But also that is a bit complex
> I think.
> 
> 
>  Regards,
>  Arnout

I'm not a big fan of that either, it's not buildroot's resposability to
do effort deduplication.
With that reasoning should we disable busybox's httpd if
lighttpd/hiawatha/boa/some other web server is enabled?
It's a thin line to walk on, lighttpd > boa so boa should be disabled,
and things like that...
Regards.
Thomas Petazzoni - July 27, 2012, 10:30 a.m.
Le Fri, 27 Jul 2012 07:26:32 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a écrit :

> I'm not a big fan of that either, it's not buildroot's resposability
> to do effort deduplication.
> With that reasoning should we disable busybox's httpd if
> lighttpd/hiawatha/boa/some other web server is enabled?
> It's a thin line to walk on, lighttpd > boa so boa should be disabled,
> and things like that...

Yes, that's what I was going to say: the full-featured "less" is an
obvious replacement for Busybox "less", but there are more complicated
cases like httpd as you said.

We definitely don't want to go down that road.

Thomas
Thomas Petazzoni - July 30, 2012, 5:23 p.m.
Le Thu, 26 Jul 2012 16:18:37 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a écrit :

> Build less after busybox if it's enabled, since we prefer the full-blown
> version over the light one if it's enabled (and busybox would overwrite
> the link when built afterwards).
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Applied, thanks.

Thomas
Arnout Vandecappelle - July 31, 2012, 2:30 p.m.
On 07/27/12 12:26, Gustavo Zacarias wrote:
> On 07/27/12 05:15, Arnout Vandecappelle wrote:
>
>> >    One alternative could be to automatically deselect less from busybox
>> >  when the full-blown less is selected.  But also that is a bit complex
>> >  I think.
>> >
> I'm not a big fan of that either, it's not buildroot's resposability to
> do effort deduplication.
> With that reasoning should we disable busybox's httpd if
> lighttpd/hiawatha/boa/some other web server is enabled?
> It's a thin line to walk on, lighttpd>  boa so boa should be disabled,
> and things like that...

  There's a big difference: for busybox, people often use the default config,
so the decision to include httpd in unconscious.  boa or lighttpd can only
be selected explicitly.

  The difficulty you mention does exist for libxml2 vs. expat, because those
are often selected automatically.

  Regards,
  Arnout

Patch

diff --git a/package/less/less.mk b/package/less/less.mk
index b758e46..c0ecf20 100644
--- a/package/less/less.mk
+++ b/package/less/less.mk
@@ -6,7 +6,8 @@ 
 
 LESS_VERSION = 444
 LESS_SITE = http://www.greenwoodsoftware.com/less
-LESS_DEPENDENCIES = ncurses
+# Build after busybox, full-blown is better
+LESS_DEPENDENCIES = ncurses $(if $(BR2_PACKAGE_BUSYBOX),busybox)
 
 define LESS_INSTALL_TARGET_CMDS
 	$(INSTALL) -m 0755 $(@D)/less $(TARGET_DIR)/usr/bin/less