On 13/04/10 5:33 PM, Neil Williams wrote: > On Tue, 13 Apr 2010 09:13:19 +1000 > Brendan Simon <bren...@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. > 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).
> 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. > Sure. Avoiding perl, python, etc is probably a good idea, especially for very thin systems. 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. > 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. > Does this mean using the host system tools and/or the host system "environment" ?? > No maintainer scripts can be safely allowed to run until after first > boot - it doesn't matter how they are written. > Why not ?? Couldn't the 'first boot' be mocked on the host system somehow ?? I'm _not_ talking about processor/system emulation (e.g. qemu). >> 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. > Phew. Does this also solve the 'first boot' issue above ?? >> * 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. > No, not necessarily busybox, but that is a valid option. 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. > > >
