[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multistrap a busybox glibc/uclibc system

On Thu, 05 Sep 2013 20:40:09 +1000
"Brendan Simon (eTRIX)" <brendan.simon@etrix.com.au> wrote:

> I'm looking at building a linux rootfs for a wireless zigbee system
> (ARM Cortex-M3 based).
> Can multistrap generate a busybox and glibc system ?

Multistrap pulls binary packages in from existing repositories. It does
not build the packages, it builds the rootfs from the binary packages,
not from source.

If you have the packages already built, multistrap can use those
packages. Multistrap does not change anything about how the packages
are built. Multistrap is a download-and-unpack tool, it does not build
packages or compile anything.

The version of busybox in Debian and Emdebian Grip does *not* support
any functionality beyond use inside an initramfs. The busybox package
would need to be reconfigured and rebuilt and put into a suitable
repository along with all of the other packages you'd need. There was a
Crush config for busybox which would do this but it has not been
updated since Lenny.
> I tried multistrap squeeze grip with packages=busybox which succeeds
> but I get busybox and coreutlis both installed.

Correct. That version of busybox is only actually useful for initramfs
manipulation. busybox supports a large range of configuration options -
this build has a lot of those options disabled.

> Can multistrap replace coreutils with busybox ?

No. Multistrap cannot change the inherent binary dependencies of
packages - it utterly relies on those being 100% correct. Grip is based
on coreutils and perl. It does not support replacing coreutils with
busybox. Debian as a whole does not support replacing coreutils with
anything. There was a debate at the time of Crush which was,
effectively, that any OS built from Debian which no longer has
coreutils is not Debian any longer.

> Can multistrap generate a busybox and uclibc system ?

Only if the packages for such a system have already been built and put
into a suitable repository. I am not aware of a uclibc package in
Debian or Emdebian which would be suitable for this task. Most packages
in Debian will not take kindly to not having coreutils, many have
undeclared dependencies on perl as perl is Essential. This is before
you start thinking about cross-compiling the package source code - this
is in the Debian packaging of key packages like udev, curl and dpkg.


These have not been updated in some time.

> Would it be grip or crush?

> What about if using baked ?  or does it have the same dependencies as
> grip (I presume so)?

Baked is a step on from either Grip or Crush. Baked does not change
anything about how the packages are built. Baked changes nothing about
package dependencies. Crush could be Baked too, it changes nothing
about how Crush was compiled.

> BTW, there only seems to be lenny baked packages.  i.e. no squeeze
> baked packages.

Correct. The tools exist to convert built packages to Baked prior to
inclusion into your own repository but there would need to be a lot of
work and testing before the packages would be ready for that stage.


Neil Williams

Attachment: signature.asc
Description: PGP signature

Reply to: