Re: How are the new docs coming along?
Quoting Erik Andersen <email@example.com>:
> 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.
Strangely enough I don't see busybox in the list :-). Do we really need full
bash functionality on a mini-debian system? Or the extended functionality of all
those tools? Of course we could give people the choice. Do the install with a
busybox and give them the option to "upgrade" to the full versions.
> 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.
Compilation could be hard/long on a small/"slow" system, is a base installation
with binary packages not a better approach? We could maybe also look at the new
debian-installer (unfortunately i do not know much about it, but they are also
working with a smaller type of package the udebs I think)
> 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.
This is certainly a decent approach. Maybe we could add source-compiling to
ipkg? (it already installs Debian binary packages)
> 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.
Good thinking. We do have an effort there to stay on good terms with the policy.
> 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).
I'm not really far on making packages because it is not such a simple process
writing those rules files (much trail and error). But we could adapt the
debhelper scripts used for installation of the packages. I was thinking of
dh_installman, dh_installdoc,... Maybe another version for our application
edh_... or so...
> 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....
If we stick to a dpkg-buildpackage approach it should be easy (to rebuild from
9) ability to apply platform specific patches before building, may be tricky
though (just an idea)
10) More stuff....
| Philippe De Swert -GNU/linux - uClinux freak-
| "GNU is the way"
| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)
| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/
Gestuurd via het webmailsysteem van het De Nayer Instituut: www.denayer.be