Closing this issue, I consider it as fully implemented and finished - if 
anything is missing (this could be docs on the homepage for example) we should 
work on it, but independent from this bugreport.

Thanks for your work, Marc!

-regards-
-mika-

I consider this stuff implemented from the code point of view (thanks a lot for 
your work, Marc!). I'd like to make sure that the documentation is according. 
Marc, might there be anything missing from your point of view?

regards,
-mika-

Michael Prokop <mika@grml.org> has uploaded a package that may fix your bug.
Please test the package and inform the maintainer whether
version 0.8.24 of grml-autoconfig works as intended or not.

Thank you

The changelog is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 05 Aug 2009 15:44:41 +0200
Source: grml-autoconfig
Binary: grml-autoconfig
Architecture: source all
Version: 0.8.24
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-autoconfig - main bootup process of a grml system
Changes: 
 grml-autoconfig (0.8.24) unstable; urgency=low
 .
   * Check for space after bootoption 'fast' so we do not conflict
     with new kernel bootoption fastboot.
   * New bootoption 'nostartx': if using startx as default bootoption
     the bootoption 'nostartx' disables automatic startup of X.
   * Apply patch by Marc Haber regarding re-work of debs, config
     and scripts handling (thanks a lot!):
     - 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.
     [Testing: issue715]
   * Drop config_cdrom_scripts(): the bootoption "script" is triggered
     by bootoption "scripts" and was never officially documented.
   * Switch wording from 'CD' to 'live mode' where possible.
   * Bump Build-Depends to debhelper >=5.
   * Bump Standard-Version to 3.8.2 (no further changes).
   * Use invoke-rc.d for starting network instead of invoking the
     init script directly.
   * Add LSB header to init script grml-autoconfig.strace.
   * Add placeholder functions for start/restart/reload/stop to
     grml-autoconfig.strace.
   * Adjust copyright file (add reference to GPL-2, adjust year).
Checksums-Sha1: 
 8eabc5d2f97f89062396ef2d1465e9f7f3ea6678 882 grml-autoconfig_0.8.24.dsc
 08f51efed18314b98f5008ec2b5692bb219d4831 56473 grml-autoconfig_0.8.24.tar.gz
 eb06b1011aa464e2c08c2586b0b66a5a62713c05 58370 grml-autoconfig_0.8.24_all.deb
Checksums-Sha256: 
 bc8422240bebb62d104cc472bc73a08597cf8ab7ba0e5ec77369053a93b1739b 882 grml-autoconfig_0.8.24.dsc
 cc378762650a55d5e3f820b62b5bb4ac9a6343156ab6030712e26d653fdce8ad 56473 grml-autoconfig_0.8.24.tar.gz
 1437ab4c89219faf878f6c62f728b2dc0c0d824232fab557821c1f9f52ae515a 58370 grml-autoconfig_0.8.24_all.deb
Files: 
 4e5b81848f5a172a83e62e2020e392c4 882 grml optional grml-autoconfig_0.8.24.dsc
 fd27d39a741f7532e22c11203930c3af 56473 grml optional grml-autoconfig_0.8.24.tar.gz
 8cf3459650f5eb8d7899442eaf45372e 58370 grml optional grml-autoconfig_0.8.24_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKeY1a2N9T+zficugRAt/aAJ92WLczESPX8vKqREpVsORBaQWJSwCgg3Na
7ddIKrOkDbHCyhpZnE/xggc=
=5Mi1
-----END PGP SIGNATURE-----

I noticed that the bootoptions from http://grml.org/config/grml-config.html are 
poorly documented in http://git.grml.org/?p=grml-
live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD (for example 
"scripts" is missing completely). We should fix that as part of the redesign. :)

regards,
-mika-

* Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 14:17]:

> > This one is uploaded manually only. So we can update it accordingly
> > and upload the docs then when we decide it's time to.

> > I suggest we document and mention which features are available in
> > <=2009.05 only and which ones are available in >2009.05.

> So there needs to be an interim version of grml-config.html which
> documents both versions' behaviors? That's a lot of extra work for
> four months...

No. Just mention that the behaviour was changed in a specific
version in a side note (like a [NOTE]-paragraph).
It's not the "four months" but people using older grml versions and
looking at the online documentation. (I'm aware of people still
using grml 0.7 being happy with that. ;))

regards,
-mika-

On Wed, Aug 05, 2009 at 12:09:27PM +0000, Michael Prokop wrote:
> Michael Prokop <mika@grml.org> added the comment:
> * Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 14:05]:
> > > You'll be automatically noticed by upload of the according
> > > grml-autoconfig package (I'll be using '[Testing: issue###]' then).
> > > The daily builds of the next day should incorporate that version
> > > then.
> 
> > Yes, but which version of the config.txt will be visible on the web in
> > the time frame between the new code committed to git and the next
> > release? The one matching the daily image or the one matching the
> > release?
> 
> You're talking about http://grml.org/config/grml-config.html ?

Yes.

> This one is uploaded manually only. So we can update it accordingly
> and upload the docs then when we decide it's time to.
> 
> I suggest we document and mention which features are available in
> <=2009.05 only and which ones are available in >2009.05.

So there needs to be an interim version of grml-config.html which
documents both versions' behaviors? That's a lot of extra work for
four months...

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

* Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 14:05]:

> > You'll be automatically noticed by upload of the according
> > grml-autoconfig package (I'll be using '[Testing: issue###]' then).
> > The daily builds of the next day should incorporate that version
> > then.

> Yes, but which version of the config.txt will be visible on the web in
> the time frame between the new code committed to git and the next
> release? The one matching the daily image or the one matching the
> release?

You're talking about http://grml.org/config/grml-config.html ?
This one is uploaded manually only. So we can update it accordingly
and upload the docs then when we decide it's time to.

I suggest we document and mention which features are available in
<=2009.05 only and which ones are available in >2009.05.

regards,
-mika-

On Wed, Aug 05, 2009 at 11:42:03AM +0000, Michael Prokop wrote:
> Michael Prokop <mika@grml.org> added the comment:
> * Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 13:38]:
> > > I'd suggest we just put it in the grml-testing repository so it
> > > becomes part of daily builds. Users with harddisk installations
> > > won't be affected at all and on the other suide it gives us a good
> > > option to test the new version with different grml flavours.
> 
> > Which version will be on the web?
> 
> You'll be automatically noticed by upload of the according
> grml-autoconfig package (I'll be using '[Testing: issue###]' then).
> The daily builds of the next day should incorporate that version
> then.

Yes, but which version of the config.txt will be visible on the web in
the time frame between the new code committed to git and the next
release? The one matching the daily image or the one matching the
release?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

* Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 13:38]:

> > I'd suggest we just put it in the grml-testing repository so it
> > becomes part of daily builds. Users with harddisk installations
> > won't be affected at all and on the other suide it gives us a good
> > option to test the new version with different grml flavours.

> Which version will be on the web?

You'll be automatically noticed by upload of the according
grml-autoconfig package (I'll be using '[Testing: issue###]' then).
The daily builds of the next day should incorporate that version
then.

regards,
-mika-

On Wed, Aug 05, 2009 at 09:21:58AM +0000, Michael Prokop wrote:
> Michael Prokop <mika@grml.org> added the comment:
> > We should think, however, about the current users which have a
> > slightly different behavior in the release version (and some features
> > less). Do you have an idea how it would be feasible to have two
> > versions of the file until the next release?
> 
> I'd suggest we just put it in the grml-testing repository so it
> becomes part of daily builds. Users with harddisk installations
> won't be affected at all and on the other suide it gives us a good
> option to test the new version with different grml flavours.

Which version will be on the web?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

* Marc 'Zugschlus' Haber <bts@bts.grml.org> [20090805 08:54]:
> On Wed, Aug 05, 2009 at 02:13:56AM +0000, Michael Prokop wrote:

> > I plan to integrate your patches within the next few days. Are there any news 
> > from your side which I should take care of or are the patches in issue715 what 
> > you'd like to see in grml-autoconfig?

> I haven't worked on the issue after submitting the patch since I
> couldn't test, so yes, that's what I would like to see committed for
> testing. This is no way release quality at the moment, and I would be
> willing to test an individually made image in the case that you
> wouldn't want risk breaking the daily images.

Ok.

> > BTW: We should bring http://git.grml.org/?p=grml-saveconfig.git;a=blob;f=grml-
> > config.txt;hb=HEAD up2date so it matches with the new myconfig layout. Any 
> > chance you could work on this?

> I will of course adapt the docs once the code has stabilized and the
> new behavior has proven to be correct.

Ok.

> We should think, however, about the current users which have a
> slightly different behavior in the release version (and some features
> less). Do you have an idea how it would be feasible to have two
> versions of the file until the next release?

I'd suggest we just put it in the grml-testing repository so it
becomes part of daily builds. Users with harddisk installations
won't be affected at all and on the other suide it gives us a good
option to test the new version with different grml flavours.

regards,
-mika-

Hi,

On Wed, Aug 05, 2009 at 02:13:56AM +0000, Michael Prokop wrote:
> I plan to integrate your patches within the next few days. Are there any news 
> from your side which I should take care of or are the patches in issue715 what 
> you'd like to see in grml-autoconfig?

I haven't worked on the issue after submitting the patch since I
couldn't test, so yes, that's what I would like to see committed for
testing. This is no way release quality at the moment, and I would be
willing to test an individually made image in the case that you
wouldn't want risk breaking the daily images.

> BTW: We should bring http://git.grml.org/?p=grml-saveconfig.git;a=blob;f=grml-
> config.txt;hb=HEAD up2date so it matches with the new myconfig layout. Any 
> chance you could work on this?

I will of course adapt the docs once the code has stabilized and the
new behavior has proven to be correct.

We should think, however, about the current users which have a
slightly different behavior in the release version (and some features
less). Do you have an idea how it would be feasible to have two
versions of the file until the next release?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Hi Marc,

I plan to integrate your patches within the next few days. Are there any news 
from your side which I should take care of or are the patches in issue715 what 
you'd like to see in grml-autoconfig?

BTW: We should bring http://git.grml.org/?p=grml-saveconfig.git;a=blob;f=grml-
config.txt;hb=HEAD up2date so it matches with the new myconfig layout. Any 
chance you could work on this?

Thanks!

regards,
-mika-

Here is the patch which also implements the config option. Please take a look 
at it and apply if you want to. This definetely needs further testing which I 
cannot do.

I also wasn't able to remove the three attachments from yesterday.

Greetings
Marc

On Tue, Jul 28, 2009 at 09:40:36PM +0000, Michael Prokop wrote:
> Michael Prokop <mika@grml.org> added the comment:
> > 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.
> 
> Highly appreciated and welcome!

Here is the first set of patches that have received only very limited
testing. I cannot remaster grml and thus had to simply re-execute the
scripts on an already running grml. The config.tbz stuff is still
missing, I just wanted to get some feedback on what I did. There is
probably some unreachable code in autoconfig.functions still, I
haven't fully cleaned up yet.

Please tell me what you think, and if you find the time, just try the
code.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

* Marc 'Zugschlus' Haber <bts at bts.grml.org> [20090728 23:18]:

> The interaction between GRMLCFG, myconfig, scripts, debs and config is
> incredibly byzantine to me. It has clearly grown,

FullACK

> 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.

Sounds great, I especially like the "merge" of existing approaches
into "central configuration" via $dcs-dir/myconfig=....

> 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.

ACK. It's important *not* to break existing configurations/setups.

> 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.

Highly appreciated and welcome!

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

Good idea, feel free to ask for opinions on the grml mailinglist.

Thanks, Marc!

regards,
-mika-

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