Nothing fixed yet, just a semi-tested idea. A conf file for multistrap could be defined as "base" and another as "variant". Variant would include only those settings from [General] that differ between variants and then a number of sections, like Grip, GripUpdate, Debian, Local etc. Base would include the core settings that don't change and maybe one section for the base packages. Settings from [General] in the variant would override those in base. (i.e. the value in base is ignored and the variant used instead.) Lists in [General] in the variant will append values from lists in base. Sections in the variant would replace those defined in base, if any. New sections in the variant would be put alongside those in base. The variant file would need a new config key: Include: /path/ where /path/ is an absolute or relative path to the base config file (relative to the location of the variant config file). A Variant file could act as a Base file for another config, under the above rules but I won't recommend nesting any deeper than that. i.e. the cascade starts with the specifics and gets more general. This allows the variant to decide which base files to include, rather than trying to embed logic into a base file that could be included by many variants. Comments? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp4ZlmRrOzSK.pgp
Description: PGP signature