Re: dpkg divert in preinst scripts

[Brendan Simon <Brendan@BrendanSimon.com>]

On 13/04/10 5:33 PM, Neil Williams wrote:

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.
  

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.