4 - arch/ is perfect (strategy design pattern)
10 PRE: Valid configuration (correct command line options, configuration file,...)
11 OK: Run target defined in configuration
12 NOT OK: Show usage, version, display exception and stop program
15 - create a catalyst configuration class (proxy design pattern), in its constructor
16 it parses sys.argv, returns a new object with configuration set, throw an exception
17 if an error occurred. Preferably in a new file. This allows to migrate for instance
18 to XML configuration later on, still allowing for the older format.
19 - global variables are not a good idea because they could be more easily overridden
20 unintentionally by a module.
22 - spec/examples/kconfig:
25 - Kernel .configs in examples/livecd and kconfig should be removed, as this is the
26 responsibility of genkernel?
27 - Spec files in examples should be listed in spec/
31 Is there a reason this needs to be done in shell script rather than with a python class
32 inheritance structure? I'm ok with reinventing inheritance using 'case' should something
33 be required that cannot be realized using python. In any case, much needs to be improved:
35 chroot ${blabla} /bin/bash << EOF
39 is prone to errors because people tend to use variables from outside the chroot in the body.
40 This also destroys indentation, and prevents reuse. A much better technique is the one used
41 in the livecd script used by ppc (gentoo/users/pvdabeel/livecd):
43 ${_VARS_} chroot ${blabla} /livecd/install-kernel.sh
44 ${_VARS_} chroot ${blabla} /livecd/install-packages.sh
45 ${_VARS_} chroot ${blabla} /livecd/remove-packages.sh
46 ${_VARS_} chroot ${blabla} /livecd/hard-cleanup.sh
47 ${_VARS_} chroot ${blabla} /livecd/configure-runlevels.sh
49 This technique allows to define several tasks that need to be run inside the chroot. This is
50 very usefull: a kde/gnome livecd could feature an extra customize-desktop.sh task.
52 Also, what happens with the mounts in the runscript on CTRL-C?
54 Emerge genkernel fails for users needing a PROXY. the ${_VARS_} before the chroot allows one
55 to solve that problem. (same for ccache, distcc, cflags...). No need to write an if then else
59 Should be considered specs.
62 A target file for each target class, comments needed for each class.
63 Generic_stage_target contains hardcoded data that should be provided in the specs (targetmap,
66 - modules/targets.py <-> targets/
68 The remark about chroot applies. The technique is illustrated in the ppc livecd script.
69 The targets/ definitely need a cleanup (is livecd/livecd.sh used?). zapmost is never called.
70 Have only looked at the livecd part. Stage part needs rework, e.g: stage1 still uses packages.build
71 rather than a spec file?
76 Variables format in /etc/catalyst.conf differs from other gentoo config files. A common approach is needed.
78 There is catalyst stuff in make.conf: GRP_STAGE23_USE, does a package know when it is rebuild whether is should
79 use these USE flags rather than those set in usr/portage/profiles/.../make.defaults? This should become a spec.
81 How to declare proxy settings to catalyst?
83 Specs use different settings than config
85 The availability of a snapshot is a pre-requirement for both stages/grp and livecd. PRE requirements should
86 be checked before doing work such as unpacking the stage. (remember: user leaves computer and returns the day
87 after and sees no snapshot was available.)
89 Incremental building requirement for livecds. If building the kernel failed in the live environment, there is no
90 need to unpack the stage3 again, install the kernel again. We only need to reconfigure it. PPC livecd scripts
91 behave like this. This allows to CTRL-C the livecd building, chroot into the live environment, make a few changes
92 and restart the script. (trick is to touch files on specific milestones).
94 I still don't know what livecd-stage1, stage2 stage3 is supposed to do. Comments/instructions needed.
96 Building custom livecds such as the kde/gnome cd might involve running an extra script inside the live environment
97 (to modify motd, issue, ...). See design remarks about targets and ppc livecd script.
102 It should be possible to describe what livecd init.d services should be added/removed, in the spec file.
104 If one has build 700M of GRP packages, these can be reused for assembling the livecd. Rebuilding all packages again
105 is a time and resource wasting process.
107 Pieter Van den Abeele