[1/5] dash: bump to version 0.5.8-1

Add hash file, make the /bin/sh -> dash symlink and build after busybox and
use $(INSTALL) instead of cp for proper mode handling.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 ...r-helpers.patch => dash-0001-no-config.h-for-helpers.patch} |  0
 package/dash/dash.hash                                         |  3 +++
 package/dash/dash.mk                                           | 10 +++++++---
 3 files changed, 10 insertions(+), 3 deletions(-)
 rename package/dash/{dash-0.5.7-no-config.h-for-helpers.patch => dash-0001-no-config.h-for-helpers.patch} (100%)
 create mode 100644 package/dash/dash.hash

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 > Add hash file, make the /bin/sh -> dash symlink and build after busybox and
 > use $(INSTALL) instead of cp for proper mode handling.

 > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
 > ---
 >  ...r-helpers.patch => dash-0001-no-config.h-for-helpers.patch} |  0
 >  package/dash/dash.hash                                         |  3 +++
 >  package/dash/dash.mk                                           | 10 +++++++---
 >  3 files changed, 10 insertions(+), 3 deletions(-)
 >  rename package/dash/{dash-0.5.7-no-config.h-for-helpers.patch => dash-0001-no-config.h-for-helpers.patch} (100%)
 >  create mode 100644 package/dash/dash.hash

 > diff --git a/package/dash/dash-0.5.7-no-config.h-for-helpers.patch b/package/dash/dash-0001-no-config.h-for-helpers.patch
 > similarity index 100%
 > rename from package/dash/dash-0.5.7-no-config.h-for-helpers.patch
 > rename to package/dash/dash-0001-no-config.h-for-helpers.patch
 > diff --git a/package/dash/dash.hash b/package/dash/dash.hash
 > new file mode 100644
 > index 0000000..0198cd8
 > --- /dev/null
 > +++ b/package/dash/dash.hash
 > @@ -0,0 +1,3 @@
 > +# From http://ftp.debian.org/debian/pool/main/d/dash/dash_0.5.8-1.dsc
 > +sha256	c6db3a237747b02d20382a761397563d813b306c020ae28ce25a1c3915fac60f	dash_0.5.8.orig.tar.gz
 > +sha256	d751769cc1ef8b825a177e782f1cd3e35bde7c268107fa4febf8d235e12c64d9	dash_0.5.8-1.diff.gz
 > diff --git a/package/dash/dash.mk b/package/dash/dash.mk
 > index 5bc0835..cc71337 100644
 > --- a/package/dash/dash.mk
 > +++ b/package/dash/dash.mk
 > @@ -4,15 +4,19 @@
 >  #
 >  ################################################################################
 
 > -DASH_VERSION = 0.5.7
 > +DASH_VERSION = 0.5.8
 >  DASH_SOURCE = dash_$(DASH_VERSION).orig.tar.gz
 >  DASH_SITE = $(BR2_DEBIAN_MIRROR)/debian/pool/main/d/dash
 > -DASH_PATCH = dash_$(DASH_VERSION)-3.diff.gz
 > +DASH_PATCH = dash_$(DASH_VERSION)-1.diff.gz
 > +# Build after since dash is better than busybox shells
 > +DASH_DEPENDENCIES = $(if $(BR2_PACKAGE_BUSYBOX),busybox)
 >  DASH_LICENSE = BSD-3c, GPLv2+ (mksignames.c)
 >  DASH_LICENSE_FILES = COPYING
 
 > +# Make /bin/sh -> dash (no other shell, better than busybox shells)
 >  define DASH_INSTALL_TARGET_CMDS
 > -	cp -a $(@D)/src/dash $(TARGET_DIR)/bin/dash
 > +	$(INSTALL) -m 0755 $(@D)/src/dash $(TARGET_DIR)/bin/dash
 > +	ln -sf dash $(TARGET_DIR)/bin/sh

So what about bash? Which one should "win"? bash?

On 10/08/2014 02:27 PM, Peter Korsgaard wrote:
> So what about bash? Which one should "win"? bash?

We can't make that determination on the user behalf if he selected
multiple shells, random order will prevail.
However we can say that any of these is more feature-complete than what
busybox has to offer.
Regards.

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 > On 10/08/2014 02:27 PM, Peter Korsgaard wrote:
 >> So what about bash? Which one should "win"? bash?

 > We can't make that determination on the user behalf if he selected
 > multiple shells, random order will prevail.
 > However we can say that any of these is more feature-complete than what
 > busybox has to offer.

Random is not good, so I suggest we either:

- Only do it for bash like today
- Provide an option for the user to select
- Decide on a fixed priority order (E.G. busybox->dash->zsh->bash) and
  tell people to use a post-build script if they are not happy with it

On 10/08/2014 03:05 PM, Peter Korsgaard wrote:

> Random is not good, so I suggest we either:
> 
> - Only do it for bash like today

That's not an option: non-usable default rootfs if there's no /bin/sh.

> - Provide an option for the user to select

It's possible, probably best in System Configuration an option that
selects the appropiate package.
I wouldn't pull in busybox though, only make the option available if
BR2_PACKAGE_BUSYBOX.
And make the symlink in target-finalize to avoid touching the packages
much (actually making them simpler).

> - Decide on a fixed priority order (E.G. busybox->dash->zsh->bash) and
>   tell people to use a post-build script if they are not happy with it

It's a pretty arbitrary decision, many people would balk at the idea of
having bash as default yet they may need it for other uses.
Regards.

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

Hi,

 > On 10/08/2014 03:05 PM, Peter Korsgaard wrote:
 >> Random is not good, so I suggest we either:
 >> 
 >> - Only do it for bash like today

 > That's not an option: non-usable default rootfs if there's no /bin/sh.

But a buildroot config without busybox is quite unlikely.


 >> - Provide an option for the user to select

 > It's possible, probably best in System Configuration an option that
 > selects the appropiate package.
 > I wouldn't pull in busybox though, only make the option available if
 > BR2_PACKAGE_BUSYBOX.
 > And make the symlink in target-finalize to avoid touching the packages
 > much (actually making them simpler).

Yes, we can do something like that if there's interest / need. I
personally don't care enough about it do it myself, but I do want
reproducible builds.

A real config with multiple (non busybox) shells is imho quite unlikely
though.


 >> - Decide on a fixed priority order (E.G. busybox->dash->zsh->bash) and
 >> tell people to use a post-build script if they are not happy with it

 > It's a pretty arbitrary decision, many people would balk at the idea of
 > having bash as default yet they may need it for other uses.

Sure it is arbitrary, but that's what we have today and I haven't heard
anybody complaining.

On 10/08/2014 03:46 PM, Peter Korsgaard wrote:

> But a buildroot config without busybox is quite unlikely.

Well that's what i'm testing here and other than the other patches
that's the only big broken thing that i've found.
For a basic boot the required packages are:

coreutils -> cat, echo, and a ton of other tiny utils
net-tools -> hostname, ifconfig and such
util-linux (agetty, fsck, kill, login utils, mount/umount)
some shell (bash, dash, zsh)

Optional but nice:

sysklogd -> a logger, not strictly necessary but convenient.
procps-ng -> ps utils.
and many others for the usual complete shell experience.

Not covered yet:

ifdown/ifup - we can package it.
start-stop-daemon - we can probably get away without it by tweaking
initscripts.

The problem is that we allow busybox to be turned off for
systemv/systemd so we've gotta cover those use cases.

>  > It's possible, probably best in System Configuration an option that
>  > selects the appropiate package.
>  > I wouldn't pull in busybox though, only make the option available if
>  > BR2_PACKAGE_BUSYBOX.
>  > And make the symlink in target-finalize to avoid touching the packages
>  > much (actually making them simpler).
> 
> Yes, we can do something like that if there's interest / need. I
> personally don't care enough about it do it myself, but I do want
> reproducible builds.
> 
> A real config with multiple (non busybox) shells is imho quite unlikely
> though.

I'll give it a shot, it shouldn't be hard.
Yes it would be odd for multiple non-busybox shells to exist, that was
my reasoning that any full shell would step on /bin/sh, see? ;)

> Sure it is arbitrary, but that's what we have today and I haven't heard
> anybody complaining.

Well, we can evolve it a bit, once the selection option is done it will
be quite easy to add new shell options which, contrary to adding a ton
of ifeqs, is nicer.
It might be interesting in the long run since we'll have to deal with
/etc/shells (not quite the same but still in the same area) for
non-busybox scenarios.

Regards.

On 08/10/14 21:16, Gustavo Zacarias wrote:
> On 10/08/2014 03:46 PM, Peter Korsgaard wrote:
> 
[snip]
>>  > It's possible, probably best in System Configuration an option that
>>  > selects the appropiate package.
>>  > I wouldn't pull in busybox though, only make the option available if
>>  > BR2_PACKAGE_BUSYBOX.
>>  > And make the symlink in target-finalize to avoid touching the packages
>>  > much (actually making them simpler).
>>
>> Yes, we can do something like that if there's interest / need. I
>> personally don't care enough about it do it myself, but I do want
>> reproducible builds.
>>
>> A real config with multiple (non busybox) shells is imho quite unlikely
>> though.
> 
> I'll give it a shot, it shouldn't be hard.
> Yes it would be odd for multiple non-busybox shells to exist, that was
> my reasoning that any full shell would step on /bin/sh, see? ;)

 Hi Gustavo,

 We discussed the sh stuff at the BR developer meeting and it would be nice if
we had:

- a config option in the system menu that lets the user select the shell: none,
busybox, dash, bash, zsh (default busybox);

- the config option selects the appropriate package;

- target-finalize creates the symlink;

- if sh is busybox, then it's up to the user to choose the appropriate
FEATURE_SH_IS_* option in busybox; we will still create the symlink to busybox
from buildroot.


 Will you take this up? Thanks!


 Regards,
 Arnout


[snip]

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 > Add hash file, make the /bin/sh -> dash symlink and build after busybox and
 > use $(INSTALL) instead of cp for proper mode handling.

 > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Committed with the /bin/sh handling removed as we'll handle it globally
instead, thanks.