[Server-devel] xs-config replacement strategy

[Martin Langhoff]

On Wed, Aug 27, 2008 at 7:50 AM, John Watlington <wad at laptop.org> wrote:
> The proposed change to the operation of the xs-config
> package seem sane, with a few comments:

Thanks!

> The make-a-replacement strategy is the crucial one.
> I have hesitations about the xs-config.make file
> used:

My replies below make reference to xs-config.make as seen here
http://dev.laptop.org/git?p=projects/xs-config;a=blob;f=altfiles/etc/xs-config.make;h=77decac9fd6014d92625872ce0179f61df60184b;hb=HEAD

> - Multiple will be needed, in each directory with changed
>  files.

I also tought so, but make actually supports saying

   make -f xs-config.make sysconfig/squid

> - Getting a correct config now requires a correct make file
>  and a correct ".in" file (plus helpers) for each file generated.

We can split the make file in many, but the current implementation is
of _one_ make file, and if the "helper" code is simple (sed, etc) it
can be just inline. Addidionally, you can share the code for many
files.

So I haven't migrated domain_config to the makefile, but doing so
would remove all the duplication...

> - It lumps together changes for multiple packages

Yes. The xs-config pkg is meant to lump many config tweaks together.
If a specific service or daemon merits its own "config" package, we
may do that. To an extent, xs-rsync is a good example: a few scripts
and configs around xinetd, rsync and incrond.

But I don't want to have to create a new pkg for _every_ damn thing we
want to override.

If we do hear from users that they want to install xs-config and
pick-and-choose what config files to override with it, we could change
the 'make all' that happens during %post to be conditional. Skip it if
/etc/sysconfig/xs-config.noauto exists, for example, and then it's up
to the user to `make $desiredconfig`

> It doesn't fix the problem with user changes being deleted ---
> the *.in file will change and a new file will be generated
> overwriting previous configuration.
>
> What did I miss ?

If the user changes /etc/foo yes we'll overwrite it. However:

 - There is a warning at the top of each conffile saying "edit the .in
version" and a hint to read the README.
 - The README explains how to recover your overwritten changes by using git.
 - The .in files are set to conffile so if you change them, your
changes in the .in file will be preserved.

cheers,



m
--
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff