On 13/04/10 5:33 PM, Neil Williams wrote:
Most of these are generic tools just compiled for a particular architecture. Can't the host tools be used to perform these activities (ehco, mv, cp, etc).On Tue, 13 Apr 2010 09:13:19 +1000 Brendan Simon <Brendan@BrendanSimon.com> wrote:The main issue I can see is _if_ the system installs binary executables that must be run on the target during configuration. Architecture independent scripts (sh, python, perl, etc) should be able to run on the host.That gets recursive very, very quickly. I don't know of any maintainer scripts that are truly architecture-neutral because even a shell script ends up calling binary executables to do the work. How much can you realistically do in a POSIX shell without calling 'cp', 'ls', 'grep', 'echo', 'mv' or 'ldconfig'? What about the shell interpreter itself? That's compiled.
Sure. Avoiding perl, python, etc is probably a good idea, especially for very thin systems.Emdebian certainly doesn't want to encourage maintainer scripts using perl or python because Crush won't support either interpreter. Even if you allow perl or python, how much can the interpreter really do without forking some compiled executables or the interpreter itself calling internal compiled code? Why do python2.6 and perl both have buildd logs - because each interpreter contains lots of compiled executables.
But some embedded systems are quite fat (have lots of memory and storage -- e.g. routers, firewalls, etc), and are quite suitable for grip packages.
Does this mean using the host system tools and/or the host system "environment" ??The other solution is a prefix - replace the interpreter location with one outside the foreign environment. The problem then is just when and how do you decide which queries and instructions need to get information from which environment? Could easily end up configuring the foreign system to work like the desktop that created it instead of the embedded device it needs to be at boot.
Why not ??No maintainer scripts can be safely allowed to run until after first boot - it doesn't matter how they are written.
Couldn't the 'first boot' be mocked on the host system somehow ?? I'm not talking about processor/system emulation (e.g. qemu).
Phew.I would like someway to configure these on the host and have them set on the target, preferably with the packages believing they are already configured, or as an alternative, configuring using a known set of values (pre-seed ??)Yes, pre-seeding is the answer. Create the configuration outside - using a native chroot that can be automatically configured as close as possible to the desired config and then tweaked to resolve corner cases - and then just dump that config onto the foreign filesystem.
Does this also solve the 'first boot' issue above ??
No, not necessarily busybox, but that is a valid option.* to build a linux embedded system based on Debian packages (and/or sources). * generate a root filesystem (or number of filesystems) that are fully pre-configured -- or partially configured on host with configuration being completed automatically (non-human interaction) on the target at end of installation process or on subsequent boot. * install filesystem on the target system (could be a done in a variety of ways. e.g. unused partition). * boot from installed filesystem.So if you're not wanting dpkg or apt on the final system, can you give me some idea of the packages you do want? Presumably busybox.
For a networking device, things like a shell interpreter, an snmp agent, an ssh server, a web server, etc.
e.g. A 'fat' networking device may have: libc6, bash, coreutils, net-snmp, openssh-server, openssl, apache.
e.g. A 'thin' networking device may have: uclibc, busybox, net-snmp, dropbear, appweb.
The approach with the Crush experiments is to allow this kind of config by providing dumb replacements for the executables/scripts called BY maintainer scripts. i.e. adduser, dpkg-divert, update-alternatives, install-info - these are simple no-op shell code that accepts any and all arguments, never returns anything other than zero and never outputs or modifies anything. What these scripts would have achieved is then left to the developer to engineer - *without* the packages getting in the way or undoing your config later. This way, we don't mind if maintainers use Debian-specific tools to do the real work within maintainer scripts because we can replace the tools with no-ops and our own changes are untouched. What we don't want is more maintainers using perl or python maintainer scripts that do all the work themselves. Not only is that duplication of effort in Debian but it also complicates pre-seeded configurations. See my other email.My current approach is to basically follow Debian, but try to interpret the maintainer scripts on the host system and translate them as required.I think the better way is to insulate your system from the effects of running the scripts.