aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--ChangeLog6
-rw-r--r--NOTES10
-rw-r--r--README22
-rw-r--r--REMARKS120
-rw-r--r--TODO5
5 files changed, 16 insertions, 147 deletions
diff --git a/ChangeLog b/ChangeLog
index f25d2c72..80a313fd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,10 @@
# ChangeLog for gentoo/src/catalyst
# Copyright 2002-2005 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo/src/catalyst/ChangeLog,v 1.226 2005/04/20 20:29:03 wolf31o2 Exp $
+# $Header: /var/cvsroot/gentoo/src/catalyst/ChangeLog,v 1.227 2005/04/20 20:42:36 wolf31o2 Exp $
+
+ 20 Apr 2005; Chris Gianelloni <wolf31o2@gentoo.org> -NOTES, README,
+ -REMARKS, -TODO:
+ Removing old files from previous maintainers and updating README.
20 Apr 2005; Chris Gianelloni <wolf31o2@gentoo.org>
modules/livecd_stage2_target.py, targets/support/livecdfs-update.sh:
diff --git a/NOTES b/NOTES
deleted file mode 100644
index 3409578e..00000000
--- a/NOTES
+++ /dev/null
@@ -1,10 +0,0 @@
-July 11, 2004
-
-If you were previously using a script to call Catalyst and pass options to it on
-the commandline (catalyst target=foo meep=yar), BEHAVIOR HAS CHANGED.
-You now need to pass Catalyst the -C (--cli) option to tell it to read the next
-arguments as a commandline. NOTE THAT -C MUST BE THE LAST ARGUMENT PASSED OR
-ELSE BREAKAGE WILL ENSUE.
-
-The old behavior exists in Catalyst <=1.0.8. The new behavior will exist in
-Catalyst >=1.0.9.
diff --git a/README b/README
index 8ebc8ff9..1f1246c8 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
-# 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
========================
@@ -18,9 +18,9 @@ your own risk.
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?
========================
@@ -31,11 +31,11 @@ the very tools you install your system with.
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
========================
@@ -47,7 +47,7 @@ Example catalyst.conf:
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
diff --git a/REMARKS b/REMARKS
deleted file mode 100644
index 322937a5..00000000
--- a/REMARKS
+++ /dev/null
@@ -1,120 +0,0 @@
-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
diff --git a/TODO b/TODO
deleted file mode 100644
index 29d69b4e..00000000
--- a/TODO
+++ /dev/null
@@ -1,5 +0,0 @@
-# Copyright 1999-2004 Gentoo Foundation
-# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo/src/catalyst/Attic/TODO,v 1.10 2004/10/15 02:48:20 zhen Exp $
-
-Fix the hardcoded arch information in modules/generic_stage_target.py