Re: multistrap a busybox glibc/uclibc system

On Thu, 05 Sep 2013 20:40:09 +1000
"Brendan Simon (eTRIX)" <[email protected]> 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.

http://www.emdebian.org/trac/browser/current/target

These have not been updated in some time.

> Would it be grip or crush?

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
=============
http://www.linux.codehelp.co.uk/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBCAAGBQJSKHMsAAoJEPFn5DyBQ7aCPVEQALBl3HFnS2N3szvej2q1/4j3
iEEw9ox7VMmBvVklZJ0g1XI/0RiuzWhW/1DIhQamRjFjpNd0x3hjwLl1VQnZ/iqT
tLYkyOoAXLtuJG0lwUrAcc8ZlnpEwaXM727ir8MlNQYi0kc8wBohNYM/70pR67Yt
Z/s+5QqvN8KYoSa65oa9qzqqND2bgflCv9JRT9Y4VUbRW7riyf0QoYwvJYXen7FT
WDzZloCZeFkShy5qDZ2wsH7u7p5G7mrqDJrqEHHd1svaC8cCJ9aQ6F1AQGONiLZX
6l5dGVdbrxiUk9obeqjDBasH5gbUIe4/zl498neWSagraOzDnA4aQI+msYiKRU6A
p9KTDE71TA804uvFOcmocNNr9Wj0MGRV8a9vx+aITH0AYudx5AzAoSpiweIgEmch
8bQPEnA9bZzWFFRX35ey67MToBzIM8P81/j49UCoFXOMWqwaw47naRAErqaE8UTz
/r98niX/JFBNaItit204fxzjKe/E2F7nNkIqt9SZEYR60YgAqcXeyvQB65GoL2UI
sX+o34C7+NCD/giR6AiuxZUJ12KwZVEpa40xVBntvWZgXoLB8WAztddJVKLrUIhi
+nuPQROP4rOah+Chwz5l4ioVJSR0nl5eVVNamCnWz9z9JShCaQM2KLQ0DgMljRbA
AehNw1kCi6NjxQ+16L45
=SENy
-----END PGP SIGNATURE-----