Re: Is emsandbox useful anymore?
+++ Neil Williams [2010-03-13 14:28 +0000]:
> I'm considering dropping emsandbox in favour of multistrap.
>
> Problems:
>
> 1. emsandbox relies on debootstrap but is not used in the way that
> debootstrap is designed to be used (inside an installer). Instead it is
> used in environments where apt and dpkg are known to already be working
> (apt is a dependency of emdebian-rootfs). There seems to be little
> reason to continue using debootstrap instead of multistrap which is
> far simpler to maintain and far more flexible in use.
Agreed. The only issue would be that emsandbox does more than
multistrap - it does machine-config scripts too, which to date
multistrap has left to external functionality. I'd like to see it gain
at least hooks for config (indeed the man page says it has such hooks,
but that's currently wrong :-)
There is something to be said for keeping multistrap simple: i.e. it
just makes rootfs's from packages. On the other hand a bit of
config/personalaisation is almost always needed so some mechanism is
needed. There are actually two aspects - the machine:variant support,
and the packing up of rootfses into suitable formats (e.g. cramfs, JFFS,
yaffs images). How much of this should go into multistrap is a useful
thing to debate.
> 2. emsandbox machine:variant support can be reimplemented (arguably
> more flexibly) with multistrap.
This would make my life easier. Currently I build images with
multistrap and then run my rootfs-config scripts on them to set up
basic config. This only really works properly for packages that deal
well with pre-supplied config files.
> Solution:
>
> 1. Drop emdebian-rootfs as a source and binary package name , rename as
> multistrap and massively simplify the dependencies. (em_multistrap
> would disappear, just a single binary called /usr/sbin/multistrap
> because the code is just as capable of native and cross usage without
> further changes.)
Yep. I'm definately in favour of that.
> 2. Migrate some files into emdebian-tools - the state of the toolchains
> makes it hard to see how to fix the empdebuild script that uses the
> other half of emdebian-rootfs (which supported empdebuild). AFAICT it
> isn't possible for empdebuild --create to complete without manual
> intervention.
What's the problem? (I don't actually use this functionality).
> 3. Start to strip out scripts like 'emsetup' and 'emchain' which are
> also fairly broken. These scripts won't survive the removal of
> apt-cross and, again, AFAICT don't actually complete at the moment
> anyway.
The function 'check my cross-toolchain is installed and works' is a
useful one. emsetup could perhaps be kept for this purpose? I've had
to explain to someone only this week how to check that. Having
'build-cross-essential' is probably helpful here too.
> This takes the guts out of the emdebian-tools top-level
> package, putting the emphasis on emdebian-buildsupport. In effect,
> emdebian-buildsupport would become the principal package and
> emdebian-tools would contain some minor extras. If it's deemed
> worthwhile, I could rename both packages, emdebian-tools could become a
> virtual package with a new emdebian-extras package or we could drop
> scripts like embug or those could move into emdebian-qa. There are
> other parts of emdebian-tools and emdebian-buildsupport that need to be
> removed too - emdebhelper.mk and em_make are no longer useful compared
> to doing the tasks later via emgrip.
I don't have strong opinions here, but that all sounds plausible.
Distinguishing between things which are useful for general cross-work
and things which are emdebian-specific is useful IMHO.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
Reply to: