
Hi,
this is what I recently filed in the BTS as issue715, and mika said that it may be a good idea to discuss my suggestion here as well.
The interaction between GRMLCFG, myconfig, scripts, debs and config is incredibly byzantine to me. It has clearly grown, but I'd like to have some more features which would be available by a re-work of the semantics.
I would like to see the following behavior implemented:
- debs, config and scripts are always searched and read from the same place ($dcs-dir). Which place this is varies, depending on GRMLCFG, noautoconfig and myconfig. - debs are searched in $dcs-dir/debs. If debs=foo is given, foo is taken as a shell wildcard for the debs being installed, paths are allowed and relative to $dcs-dir. - config archives (config.tbz) are searched directly in $dcs-dir. If config=foo is given and foo is a file, that file is unpacked and its content taken as configuration archive. If config=foo is given and foo is a directory, the contents of the directory tree is copied over the live CD configuration. paths are allowed and relative to $dcs-dir - scripts are searched in $dcs-dir/scripts. If scripts=foo is given and foo is a file, that file is executed. If scripts=foo is given and foo is a directory, all files inside that directory are executed. Paths are allowed and relative to $dcs-dir. - If no GRMLCFG partition is found and noautoconfig is _not_ given on the command line, nothing is changed and the dcs files are searched within the .iso, $dcs-dir is set to the root directory within the .iso - If a GRMLCFG partition is found, $dcs-dir is set to the root of the GRMLCFG partition unless noautoconfig is set. If noautoconfig is set, $dcs-dir is set to the root directory within the .iso. - If myconfig=foo is set on the command line, $dcs-dir is set to foo, even if a GRMLCFG partition is present.
I tried to craft this new behavior not to break mainstream configurations while some more exotic schemes now need different handling. It also has the advantage of having similiar definitions for scrips, debs and config which will probably allow some code to be re-used for all three cases.
Please indicate whether you find this behavior acceptable and desireable. If this new behavior would break a setup you use, please say so as well. I believe this new behavior can be implemented alone by changing /etc/init.d/grml-autoconfig and/or /etc/grml/autoconfig.functions.
Greetings Marc