Re: How are the new docs coming along?
Mostly some random thoughts to get discussion moving....
Debian Embedded -- building
----------------------------
1) Create a minimalist set of packages needed to bootstrap a new system.
This will be called the "bootstrap system". This bootstrap system
will be cross compiled (if necessary) for the target architecture.
i) Components will include:
kernel-headers, coreutils, findutils, bash, make, diffutils,
patch, sed, ed, flex, bison, file, gawk, tar, grep, ncurses,
zlib, m4, autoconf, automake, libtool, perl, ncurses, zlib,
tetex-bin, and glibc or uclibc.
2) Source code for the entire Debian system that will be built must
be fetched and unpacked, presumably by using 'apt-get source'
for each package. The list of packages will initially be obtained
by extracting the list from the debian "debootstrap" package,
and merging it with the list of "essential" and "build-essential"
packages, as described in the Debian Policy Manual, chapter 4.2.
3) Boot into the "bootstrap system" (or chroot into it if possible) so
you are running entirely within the bootstrap system, and can
directly compile and run application code for the target architecture.
4) A script is then run that operates within the facilities of the
bootstrap system.
i) It will first compile and install dpkg.
ii) It will then use 'dpkg-buildpackage -us -uc -d' to compile
and install (using 'dpkg --force-depends -i') each package
that is already contained within the bootstrap system
(i.e. coreutils, bash, make, etc).
iii) It will then compile and install each package in the
debian-embedded base system.
iv) This won't work using stock debian source, due to tons
of circular dependancies.
5) Trying to do all this stuff running nativly on, say, an arm
box is going to take forever. I _strongly_ recommend the
emdebian project adopt ScratchBox (http://www.scratchbox.org/)
for building systems, since it allows you to cross compile while
your system thinks it is doing a native build. It is _very_
cool. I have seen it operation, and it works great.
Debian Embedded -- policy
----------------------------
1) All packages within the Debian embedded system shall
provide any and all documentation in a separate package.
Contrary to debian policy Chapter 12, debian-embedded
packages containing binaries shall not place anything
within the /usr/share/doc/, /usr/share/man/, and /usr/share/info/
directories. All such documentation, if provided at all,
shall be provided in an entirely separate package.
Currently many packages depend on obscure documentation
tools which often results in very complex and/or circular
build dependancies which prevents packages from building.
Seperating the documentation packages greatly simplifies
the build-depends dependancy tree, and makes it feasible
to build debian from scratch.
2) No documentation-only Debain pacakges shall be compiled initially.
If built at all, such packages will be compiled later (i.e.
after all the strange documentation tools that are needed
have been built).
3) Each package should be built with attention paid to size
optimization. Unless there is a good reason to do
otherwise, most packages should be compiled with the "-Os"
gcc flag. Care should be taken to minimize the footprint
of each package, and eliminate needless junk.
4) Contrary to standard Debian policy 11.8.1, programs that
can be configured with support for the X Window System
should _not_ be configured to do. Instead, a separate
package should be created for the X11 and non-X packages.
Similarly, programs that can be built supporting different
windowing systems, gui toolkits, and scripting languages
made into separate packages.
5) The init process may not provide support for multiple runlevels.
The description in Debian Policy Manual, chapter 9.3, is
therefore modified to consider systems which potentially
have just 1 runlevel that is used at boot time, systems
with 2 runlevels (boot and shutdown), and systems with
N runlevels. To avoid needing to change many packages,
systems supporting just 1 runlevel shall use /etc/rc2.d/
for all init scripts that are to run on bootup. Systems
that use 2 runlevel shall use /etc/rc2.d/ for their
bootup scripts, and shall use /etc/rc6.d/ for the scripts
that are run when rebooting and/or halting the system.
6) Minimizing system boot time is essential for most embedded
systems. Init scripts shall be run in parallel.
*) Proper GPG signature verification, package control, etc.
7) Enable/Disable i18n/i10n????
8) To avoid the inertia of a zillion packages worth of
deadweight, rebuilding the world from source (similar to
gentoo) needs to be easy....
9) More stuff....
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Reply to: