| Message ID | 1343330317-24730-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Accepted |
| Headers | show |
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,
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.
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. >
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
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.
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
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
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
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
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(-)