On Jun 17 15:15, Eric Blake wrote:
> On 06/17/2015 02:57 PM, Yaakov Selkowitz wrote:
> > On Wed, 2015-06-17 at 22:25 +0200, Christian Franke wrote:
> >> Busybox does not use autoconf or similar. It requires manual platform 
> >> specific configuration which does not yet support a missing 
> >> sethostname(). After adding HAVE_SETHOSTNAME manually and some other 
> >> minor additions, busybox (which many commands enabled) compiles and 
> >> works reasonably.
> >> Would ITP make sense ?
> > 
> > TBH I'm not sure.  Presuming you're discussing the single-executable
> > build (so as not to clobber coreutils etc.), there is still the question
> > of (not) matching the heavily-patched coreutils wrt .exe handling etc.
> > What do you think the use case would be?
> 
> Portability testing is one thing - I often compare how
> bash/dash/zsh/mksh handle a shell construct, and adding busybox sh into
> the mix adds another perspective.  But yeah, I don't see busybox
> becoming the default source of these apps, so much as an alternative
> implementation.

If it's called "busybox" and the package doesn't try to create shortcuts
/bin/sh -> /bin/busybox, etc, I don't see a problem to ITP it.

If those symlinks are required for busybox to work, they should be
encapsulated in their own subdir, something like /usr/libexec/busybox
or so.  Users just need to set $PATH correctly then.  Or maybe that
could be done by busybox as well.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat