Re: multistrap a busybox glibc/uclibc system
So am I right in assuming that emdebian grip (stripped down debian) is
the only real option to generate a debian based rootfs for an arm
target? it would install apt/dpkg and I would need to run "dpkg
--configure -a" on the target.
Emdebian grip baked is also an option. The same as above except that
apt/dpkg is not installed, and configuration files must be installed by
some other means. right?
For a busybox or uclibc system I must use another tool/system
altogether. e.g. buildroot, openembedded, etc, right?
Just a thought bubble. Would/could multistrap be made to work with the
opkg packaging format? openwrt and openembedded use this for the uclibc
based packages. I wonder if it is viable to make multistrap work with
that to generate uclibc root filesystems? or is multistrap so
intrinsically tied to Debian that it would be too much effort?
Thanks, Brendan.
On 5/09/13 10:03 PM, Neil Williams wrote:
> 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 ?
> 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.
>
Reply to: