Skip to Content.
Sympa Menu

sm-commit - [SM-Commit] GIT changes to master cauldron by Justin Boffemmyer (07872cd7afda30af2edbd548c2abf8ded009b403)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Justin Boffemmyer <scm AT sourcemage.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: [SM-Commit] GIT changes to master cauldron by Justin Boffemmyer (07872cd7afda30af2edbd548c2abf8ded009b403)
  • Date: Sun, 23 Nov 2008 14:01:53 -0600

GIT changes to master cauldron by Justin Boffemmyer <flux AT sourcemage.org>:

CAULDRON_DESIGN.txt | 68
----------------------------------------------------
DESIGN | 68
++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+), 68 deletions(-)

New commits:
commit 07872cd7afda30af2edbd548c2abf8ded009b403
Author: Justin Boffemmyer <flux AT sourcemage.org>
Commit: Justin Boffemmyer <flux AT sourcemage.org>

renamed CAULDRON_DESIGN.txt -> DESIGN

diff --git a/CAULDRON_DESIGN.txt b/CAULDRON_DESIGN.txt
deleted file mode 100644
index cf3597a..0000000
--- a/CAULDRON_DESIGN.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-The basic toolchain can/should be gotten from the running host system. This
-can be accomplished by using binary caches from /var/cache/sorcery. If the
-cache file for a given toolchain spell does not exist, it should NOT be
-taken from a repository somewhere, or from a basesystem tarball. Nor should
the
-iso builder have to re-cast one of the tool-chain components in order to
-generate the cache file for use. Rather, it should be taken from the already
-existing installed files on the system. This will require sorcery to generate
-binary tarballs of installed spells. If it doesn't do this already, a
solution
-can be had by grabbing files from the installwatch logs (/var/state/sorcery?)
-and rolling those into a tarball. (I believe devel sorcery handles this
-situation.)
-
-In the event that the host system does not have a build toolchain itself (an
-embedded system, for example, or a system geared for security), then a
-basesystem tarball will be needed. However, for the intents and purposes of
-Cauldron, that basesystem will then be considered the host system, so the
same
-discussion as above still applies.
-
-Once the basic tool-chain tarball is generated/found/copied, it can be
unpacked
-inside of the iso build directory. This, along with a copy of sorcery, should
-provide everything needed to generate the iso (aside from the spell packages
-themselves, which should be gotten over the net or copied in manually from
-pre-downloaded files. For grabbing over the net, a proper resolv.conf will be
-needed inside the iso build chroot).
-
-The settings for sorcery should be set for the target system (target cpu,
-etc.). For optimizations, strip should be used. The question of whether -Os
-should be used or not depends on how stable the resulting builds will be for
-the minimal architecture to be supported by the iso being built (e.g. i486,
-x86_64). If -Os will cause problems for some machines to boot the iso which
the
-iso was intended to boot on, then it obviously should not be used. If -Os can
-be used without causing any problems for the booting of the iso on the target
-systems, -Os should be used in addition to --strip in order to reduce the
size
-of the iso.
-
-Afterwards, a basic system can be built inside the iso build chroot using
-sorcery and the configured tool-chain. This basic system should be absolutely
-minimal, as it will be what is installed onto the target system. After the
-base system is generated/built, the chroot should be exited, and a copy
should
-be made into a bzipped tarball. Don't forget to clean out unnecessary files
-from the COPY, _not_ the original, before making the bzipped tarball.
-[system.tar.bz2] (unnecessary files will include the host (cross-compile)
-tool-chain used to build the base system, as well as [possibly] sorcery files
-in /var, anything in /usr/src, etc.)
-
-Chroot back into the main iso build dir (i.e. not the system install copy).
-Build the iso system by casting additional spells on top of the base system
-generated in the previous step. This includes a kernel (config for the kernel
-SHOULD be something downloaded from a repository), filesystem tools
-(reiserfstools, xfstools, e2fstools, etc.), and anything else required not
only
-to boot the target system but manipulate and install onto it. This means that
-all features desired in the installer must be present or provided for through
-the spells cast in this step or the previous step (though very little should
-come from the previous step, as the previous step should really only provide
an
-absolute minimal tool-chain generated for the target system).
-
-Configure the boot/init process for the iso. This includes modifying
-isolinux/isolinux.cfg, as well as various scripts/configs in /etc, as well as
-generating an initrd/initramfs for the ISO. Pay particular attention to the
-init system (including what will happen "before init"). (Whether or not other
-bootloaders, such as grub, can be used as viable alternatives to isolinux
will
-be researched later.)
-
-Exit the iso build chroot. Make a new copy of the iso build dir. This new
copy
-will become the iso itself. Remove any unnecessary files/packages/etc. from
-the iso. Copy in the bzipped tarball of the system install (system.tar.bz2)
and
-the initrd/initramfs. Generate a bootable iso using mkisofs. Compress the iso
-using bzip2. [e.g. smgl-devel.iso.bz2]
diff --git a/DESIGN b/DESIGN
new file mode 100644
index 0000000..cf3597a
--- /dev/null
+++ b/DESIGN
@@ -0,0 +1,68 @@
+The basic toolchain can/should be gotten from the running host system. This
+can be accomplished by using binary caches from /var/cache/sorcery. If the
+cache file for a given toolchain spell does not exist, it should NOT be
+taken from a repository somewhere, or from a basesystem tarball. Nor should
the
+iso builder have to re-cast one of the tool-chain components in order to
+generate the cache file for use. Rather, it should be taken from the already
+existing installed files on the system. This will require sorcery to generate
+binary tarballs of installed spells. If it doesn't do this already, a
solution
+can be had by grabbing files from the installwatch logs (/var/state/sorcery?)
+and rolling those into a tarball. (I believe devel sorcery handles this
+situation.)
+
+In the event that the host system does not have a build toolchain itself (an
+embedded system, for example, or a system geared for security), then a
+basesystem tarball will be needed. However, for the intents and purposes of
+Cauldron, that basesystem will then be considered the host system, so the
same
+discussion as above still applies.
+
+Once the basic tool-chain tarball is generated/found/copied, it can be
unpacked
+inside of the iso build directory. This, along with a copy of sorcery, should
+provide everything needed to generate the iso (aside from the spell packages
+themselves, which should be gotten over the net or copied in manually from
+pre-downloaded files. For grabbing over the net, a proper resolv.conf will be
+needed inside the iso build chroot).
+
+The settings for sorcery should be set for the target system (target cpu,
+etc.). For optimizations, strip should be used. The question of whether -Os
+should be used or not depends on how stable the resulting builds will be for
+the minimal architecture to be supported by the iso being built (e.g. i486,
+x86_64). If -Os will cause problems for some machines to boot the iso which
the
+iso was intended to boot on, then it obviously should not be used. If -Os can
+be used without causing any problems for the booting of the iso on the target
+systems, -Os should be used in addition to --strip in order to reduce the
size
+of the iso.
+
+Afterwards, a basic system can be built inside the iso build chroot using
+sorcery and the configured tool-chain. This basic system should be absolutely
+minimal, as it will be what is installed onto the target system. After the
+base system is generated/built, the chroot should be exited, and a copy
should
+be made into a bzipped tarball. Don't forget to clean out unnecessary files
+from the COPY, _not_ the original, before making the bzipped tarball.
+[system.tar.bz2] (unnecessary files will include the host (cross-compile)
+tool-chain used to build the base system, as well as [possibly] sorcery files
+in /var, anything in /usr/src, etc.)
+
+Chroot back into the main iso build dir (i.e. not the system install copy).
+Build the iso system by casting additional spells on top of the base system
+generated in the previous step. This includes a kernel (config for the kernel
+SHOULD be something downloaded from a repository), filesystem tools
+(reiserfstools, xfstools, e2fstools, etc.), and anything else required not
only
+to boot the target system but manipulate and install onto it. This means that
+all features desired in the installer must be present or provided for through
+the spells cast in this step or the previous step (though very little should
+come from the previous step, as the previous step should really only provide
an
+absolute minimal tool-chain generated for the target system).
+
+Configure the boot/init process for the iso. This includes modifying
+isolinux/isolinux.cfg, as well as various scripts/configs in /etc, as well as
+generating an initrd/initramfs for the ISO. Pay particular attention to the
+init system (including what will happen "before init"). (Whether or not other
+bootloaders, such as grub, can be used as viable alternatives to isolinux
will
+be researched later.)
+
+Exit the iso build chroot. Make a new copy of the iso build dir. This new
copy
+will become the iso itself. Remove any unnecessary files/packages/etc. from
+the iso. Copy in the bzipped tarball of the system install (system.tar.bz2)
and
+the initrd/initramfs. Generate a bootable iso using mkisofs. Compress the iso
+using bzip2. [e.g. smgl-devel.iso.bz2]



  • [SM-Commit] GIT changes to master cauldron by Justin Boffemmyer (07872cd7afda30af2edbd548c2abf8ded009b403), Justin Boffemmyer, 11/23/2008

Archive powered by MHonArc 2.6.24.

Top of Page