-# Copyright 1999-2004 Gentoo Foundation
+# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo/src/catalyst/README,v 1.11 2004/10/15 02:50:38 zhen Exp $
+# $Header: /var/cvsroot/gentoo/src/catalyst/README,v 1.12 2005/04/20 20:42:36 wolf31o2 Exp $
Licensing
========================
Requirements
=======================
--Python
--Gentoo Linux Portage
--GNU gcc, glibc, binutils
+- Python 2.3 or greater
+- A portage snapshot
+- A Gentoo seed stage tarball
What is Catalyst?
========================
Catalyst is capable of:
--Building installation stages for every architecture supported by Gentoo.
--Building bootable LiveCDs for every architecture supported by Gentoo.
--Building GRP (Gentoo Reference Platform) sets for every architecture supported by Gentoo.
--Setting up a Tinderbox target for test building.
--Building netboot images.
+- Building installation stages for every architecture supported by Gentoo.
+- Building bootable LiveCDs for every architecture supported by Gentoo.
+- Building GRP (Gentoo Reference Platform) sets for every architecture supported by Gentoo.
+- Setting up a Tinderbox target for test building.
+- Building netboot images.
Configuring catalyst
========================
distdir="/usr/portage/distfiles"
options="ccache pkgcache"
-sharedir="/usr/share/catalyst/modules"
+sharedir="/usr/lib/catalyst"
There are many more options that can be set, but those defaults are good
for out of the box operation. For more documentation on what you can do
+++ /dev/null
-DESIGN REMARKS
---------------
-
-- arch/ is perfect (strategy design pattern)
-
-- Catalyst
-
- idea:
-
- PRE: Valid configuration (correct command line options, configuration file,...)
- OK: Run target defined in configuration
- NOT OK: Show usage, version, display exception and stop program
-
- Suggestions:
- - create a catalyst configuration class (proxy design pattern), in its constructor
- it parses sys.argv, returns a new object with configuration set, throw an exception
- if an error occurred. Preferably in a new file. This allows to migrate for instance
- to XML configuration later on, still allowing for the older format.
- - global variables are not a good idea because they could be more easily overridden
- unintentionally by a module.
-
-## Fixed, zhen@gentoo.org
-- spec/examples/kconfig:
-
- Suggestions:
- - Kernel .configs in examples/livecd and kconfig should be removed, as this is the
- responsibility of genkernel?
- - Spec files in examples should be listed in spec/
-
-- examples/livecd:
-##
-
-## Fixed, zhen@gentoo.org
- Is there a reason this needs to be done in shell script rather than with a python class
- inheritance structure? I'm ok with reinventing inheritance using 'case' should something
- be required that cannot be realized using python. In any case, much needs to be improved:
-
- chroot ${blabla} /bin/bash << EOF
- body
-EOF
-
- is prone to errors because people tend to use variables from outside the chroot in the body.
- This also destroys indentation, and prevents reuse. A much better technique is the one used
- in the livecd script used by ppc (gentoo/users/pvdabeel/livecd):
-
- ${_VARS_} chroot ${blabla} /livecd/install-kernel.sh
- ${_VARS_} chroot ${blabla} /livecd/install-packages.sh
- ${_VARS_} chroot ${blabla} /livecd/remove-packages.sh
- ${_VARS_} chroot ${blabla} /livecd/hard-cleanup.sh
- ${_VARS_} chroot ${blabla} /livecd/configure-runlevels.sh
-
- This technique allows to define several tasks that need to be run inside the chroot. This is
- very usefull: a kde/gnome livecd could feature an extra customize-desktop.sh task.
-##
-
- Also, what happens with the mounts in the runscript on CTRL-C?
-
- Emerge genkernel fails for users needing a PROXY. the ${_VARS_} before the chroot allows one
- to solve that problem. (same for ccache, distcc, cflags...). No need to write an if then else
- for each of them.
-
-- files:
- Should be considered specs.
-
-## partially done, each module has its own file now, but still need to remove
-# the hardcoded data, zhen@gentoo.org
-- modules/targets.py:
- A target file for each target class, comments needed for each class.
- Generic_stage_target contains hardcoded data that should be provided in the specs (targetmap,
- machinemap)
-##
-
-## partially done, targets is cleaned up, but the build.sh stuff does need moved into a
-# spec file, zhen@gentoo.org
-- modules/targets.py <-> targets/
-
- The remark about chroot applies. The technique is illustrated in the ppc livecd script.
- The targets/ definitely need a cleanup (is livecd/livecd.sh used?). zapmost is never called.
- Have only looked at the livecd part. Stage part needs rework, e.g: stage1 still uses packages.build
- rather than a spec file?
-##
-
-RUNTIME REMARKS
----------------
-
-Variables format in /etc/catalyst.conf differs from other gentoo config files. A common approach is needed.
-
-There is catalyst stuff in make.conf: GRP_STAGE23_USE, does a package know when it is rebuild whether is should
-use these USE flags rather than those set in usr/portage/profiles/.../make.defaults? This should become a spec.
-
-## done, envscript option added, zhen@gentoo.org
-How to declare proxy settings to catalyst?
-##
-
-Specs use different settings than config
-
-The availability of a snapshot is a pre-requirement for both stages/grp and livecd. PRE requirements should
-be checked before doing work such as unpacking the stage. (remember: user leaves computer and returns the day
-after and sees no snapshot was available.)
-
-Incremental building requirement for livecds. If building the kernel failed in the live environment, there is no
-need to unpack the stage3 again, install the kernel again. We only need to reconfigure it. PPC livecd scripts
-behave like this. This allows to CTRL-C the livecd building, chroot into the live environment, make a few changes
-and restart the script. (trick is to touch files on specific milestones).
-
-I still don't know what livecd-stage1, stage2 stage3 is supposed to do. Comments/instructions needed.
-
-Building custom livecds such as the kde/gnome cd might involve running an extra script inside the live environment
-(to modify motd, issue, ...). See design remarks about targets and ppc livecd script.
-
-Update 25022004:
-----------------
-
-It should be possible to describe what livecd init.d services should be added/removed, in the spec file.
-
-If one has build 700M of GRP packages, these can be reused for assembling the livecd. Rebuilding all packages again
-is a time and resource wasting process.
-
-Pieter Van den Abeele
-pvdabeel@gentoo.org
projects / catalyst.git / commitdiff