REMARKS

   1 DESIGN REMARKS
   2 --------------
   3
   4 - arch/ is perfect (strategy design pattern)
   5
   6 - Catalyst
   7
   8   idea:
   9
  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
  13
  14   Suggestions:
  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.
  21
  22 - spec/examples/kconfig:
  23
  24   Suggestions:
  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/
  28
  29 - examples/livecd:
  30
  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:
  34
  35   chroot ${blabla} /bin/bash << EOF
  36         body
  37 EOF
  38
  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):
  42
  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
  48
  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.
  51
  52   Also, what happens with the mounts in the runscript on CTRL-C?
  53
  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
  56   for each of them.
  57
  58 - files:
  59   Should be considered specs.
  60
  61 - modules/targets.py:
  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,
  64   machinemap)
  65
  66 - modules/targets.py <-> targets/
  67
  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?
  72
  73 RUNTIME REMARKS
  74 ---------------
  75
  76 Variables format in /etc/catalyst.conf differs from other gentoo config files. A common approach is needed.
  77
  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.
  80
  81 How to declare proxy settings to catalyst?
  82
  83 Specs use different settings than config
  84
  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.)
  88
  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).
  93
  94 I still don't know what livecd-stage1, stage2 stage3 is supposed to do. Comments/instructions needed.
  95
  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.
  98
  99 Update 25022004:
 100 ----------------
 101
 102 It should be possible to describe what livecd init.d services should be added/removed, in the spec file.
 103
 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.
 106
 107 Pieter Van den Abeele
 108 pvdabeel@gentoo.org