From fdc7865b59447e6c1dee8f219ce3af1b263d04a9 Mon Sep 17 00:00:00 2001 From: Chris Gianelloni Date: Wed, 20 Apr 2005 20:42:36 +0000 Subject: [PATCH] Removing old files from previous maintainers and updating README. git-svn-id: svn+ssh://svn.gentoo.org/var/svnroot/catalyst/trunk@612 d1e1f19c-881f-0410-ab34-b69fee027534 --- ChangeLog | 6 ++- NOTES | 10 ----- README | 22 +++++----- REMARKS | 120 ------------------------------------------------------ TODO | 5 --- 5 files changed, 16 insertions(+), 147 deletions(-) delete mode 100644 NOTES delete mode 100644 REMARKS delete mode 100644 TODO 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 -NOTES, README, + -REMARKS, -TODO: + Removing old files from previous maintainers and updating README. 20 Apr 2005; Chris Gianelloni 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 -- 2.26.2