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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
