[Debtags-devel] Tweaking configurations

[Micah Anderson]

Holgar,

Thanks for this great summary, and kicking off some interesting
discussions.

> The three main technical challenges each CDD faces are:
> 
> 1. select the packages for the CDD
> 2. tweak them (adapt the package configuration to the CDDs need)
> 3. create a package archive and install media

I would like to spend some time fleshing out #2 since this one keeps
me up at night, number 3 is moving along quite nicely with many
different solutions that are coming together. Number 1 has had a lot
of discussion here, debtags vs. cddtk, metapackages, etc. it seems to
be converging on some common understandings of good ways to move
forwards. I dont want to change the discussion away from those
efforts, I simply am interested in #2.

CDD package configuration needs attention. I was really disappointed
that I could not attend the CDD gathering in Spain, for I wanted to
have a focused conversation about this issues. I consider this to be
the largest unsolved problem, and there are a number of potential
solutions out there that have not even been given the slightest
attention. 

The strategies that Holgar summarized are good ones that we've all
come up with as the obvious ones based on what we have before us.

However they all seem to have their individual inadequacies:

> - use plain debian if possible
This one is useful for some packages, only those that are set with
good defaults and do not need any local changes on any level.

> - use debconf preseeding if possible
This one is limited in a number of ways, in scope and scalability,
this depends on the package maintainer who could potentially be a
roadblock refusing to adopt low-priority questions, or may become
innundated with too many (in fact I would argue that this puts the
configuration side too much on the maintainer, when the maintainer
should just be doing as little as possible to enable as much
configuration as possible on the CDD's side), and the final reason
being one that Sergio illuminated in a recent email: good for initial
installation, but bad for maintenance

> - use tweaks - see http://wiki.jones.dk/DebianTweaks

This is not flushed out at all, and needs a lot more discussion,
cfengine is the only real option presented thus far. Many people end
up making custom scripts, or special packages that modify
configuration files, thus breaking debian policy. I have heard hints
in the original thread that perhaps FAI could accomplish some of these
in the form of "FAI-Classes". However, this seems to require debconf,
cfengine and scripts.

> - repackage

We all know what this means, way too much work. It solves the
problem, but breaks policy and people's backs.

There is also the multi-layered configuration approach, which I
believe was discussed in Spain, this too is a good possibility.

I would argue that we need to investigate some other options that are
out there, some of which may be seen as radical in their approach, but
perhaps such thing is needed to solve a difficult problem.

One such possibility is The Elektra Initiative
(http://elektra.sourceforge.net/), I encourage everyone to read that
webpage. This is a vibrant project that seems to have received a lot
of traction, and will probably go far. If it were adopted in Debian it
could really move quickly. The objective of the Elektra Initiative is
to create a pervasive, ubiquitous configuration system. This is an
entire ecosystem, much more than a piece of code. 

The main problem with solving a configuration problem from a CDD
perspective is that Unix is a collection of different pieces of
software, each with their own "selfish" configuration. There are no
common configuration formats. The Elektra Project is an attempt to
create a "backend" for all configuration formats so that there is a
common way to access configurations. Its a simple and consistant API
to handle this problem.

Now before everyone turns their noses to the sky and says "registry",
lets look at this with an open mind. A registry is typically known as
problematic on certain OS' due to centralization, security and
consistency problems. However, Elektra doesn't fall into this trap, it
is just a library to access files according to a namespace, if it is
unavailable, the entire system is not.

There are other systems out there as well that we have not really
assessed their relative strengths and weaknesses. For example,
Config4GNU (http://freedesktop.org/Software/CFG) is one that has a
multi-layered configuration approach, which I do not know too much
about but looks also promising.

What do others think?

micah