On 13/04/10 1:36 AM, Simon Richter wrote:
> That is the exact definition of "Essential: yes". Bootstrapping a system
> works by unpacking essential packages, then using that system to install
> the essential packages again (running their preinst in the process and
> registering the files with dpkg), then installing anything else that may
> be desired.
>
> Within emdebian, we do not want to use this method of installation
> really (although it works, it requires the target system to have enough
> space so it can run the second stage, which requires all the packages in
> the target fs, and also overwrites all files, which is quite
> unnecessary); rather, we want to be able to do everything on the host
> system.
>
Absolutely. The aim should be to avoid using the target system at all,
except for final install :)
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.
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 ??)
In fact, I don't have a requirement for dpkg, apt, etc to be installed
or run on the target.
My main requirement is:
* 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.
> My current approach is to basically follow Debian, but try to interpret
> the maintainer scripts on the host system and translate them as
> required. My first implementation goes toward full static analysis (so
> we can decide whether the installation will work before trying it), I'm
> not sure whether it will actually work this way, or if we have to start
> deferring such decisions and possibly abort in the middle of things.
>
Determining before trying would be ideal. Aborting during install is
not ideal at all -- especially if your talking about an install/upgrade
to a live system. It's ok to abort at any stage during the build
process on the host, or during the install/upgrade to target if
installing to a non-live system (e.g. an unused partition).
Cheers,
Brendan.
