[issue715] suggested re-work of myconfig, GRMLCFG, config, debs and scripts

[Marc 'Zugschlus' Haber]

New submission from Marc 'Zugschlus' Haber <mh+bts-grml at zugschlus.de>:

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.

This behavior was carefully crafted 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 and whether you would accept a patch creating part or all
of this behavior. I believe this can be done alone by changing
/etc/init.d/grml-autoconfig and/or /etc/grml/autoconfig.functions.

If you find this discussion more appropriate on a mailing list, please
say so and I'll happily repost.

Greetings
Marc

----------
messages: 2366
nosy: zugschlus
priority: wish
status: unread
title: suggested re-work of myconfig, GRMLCFG, config, debs and scripts

_____________________________________
GRML issue tracker <bts at bts.grml.org>
<http://bts.grml.org/grml/issue715>
_____________________________________