Re: How are the new docs coming along?
Quoting Erik Andersen <andersen@codepoet.org>:
> 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
source)
9) ability to apply platform specific patches before building, may be tricky
though (just an idea)
10) More stuff....
greets,
Philippe
| 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
Reply to: