Re: dpkg divert in preinst scripts

[Brendan Simon <Brendan@BrendanSimon.com>]

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.