-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20-05-2005 03:39, Micah Anderson wrote:
>>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, I think my model of "5th config layer" has not yet been presented here, and I think it is relevant for this discussion. In the Unix world before distributions we had 3 layers of configuration. The imprtant thing here is not presedence of each layer, but who is responsible for them: 1) Author (defaults hardcoded into the app/tool/daemon/whatever) 2) Admin (system-wide defaults below /etc ) 3) User (dot-config files at each home) Admins and users should RTFM and that's that. Distributions introduced an additional layer of configuration: 1) Author 2) Distro (Tweaks done for more sane behaviour within distro) 3) Admin 4) User Authors (mostly) expect distro and admin working closely together. Admins and users expect distro and author working closely together. The fine art of the distro "packaging" is (when looking at config responsibility) to hack "just enough and not more". Just enough to make the code integrate nicely with whatever is defined as "distro". Not more than the admin and users still experience the software as coming from the author. Helper "glue" like autotools was invented for authors to ease the job of distros, but when authors fail to use those tools correctly, distros fall back to hacking again, and lots and even today lots of Debian packages still need a few "distro tweaks" to compile neatly for the Debian distro. CDDs introduce a fifth layer of configuration: 1) Author 2) Distro 3) CDD (tweaks applied to distro before/while maintained by admin) 4) Admin 5) User The fine art of tweaking is similarly to that of a distro: hack "just enough and not more". Current state of CDD hacking is different in one important way, though: The hack is not (yet?) recognized either upstream by distro or downstream by admin. So the hack has to be _extremely_ small - virtually invisible: By the distro it must look like work of the admin (for maintainance routines like upgrade to work properly), and by the admin it must look like the work of the distro (to avoid surprises like questions about changes the admin didn't even know about). Keep that last sentence in mind for the following... >>- 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. Still we must mention this always when listing possibilities - to remind ourselves that the ultimate goal gotta be to convince upstream to adopt our hacks, however clever we make them. The alternative is way more complex: Convince Debian to separate configuration maintainance from packaging, to ease CDD creation without repackaging binaries. Not insane, but certainly not as easy or quick! >>- 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 What was that mail from Sergio? Sounds like what I describe above as a "stealth" requirement of CDD hacks, no? The proposed routines in the cddtk of saving original config and comparing md5 of an additional layer seems to solve this, but is quite complex and (I think) still breaks for upgrades requiring larger changes to config files: For some problematic upgrades the maintainer scripts parse the active config files and generate new ones based on them (like when switching from flatfile to XML-based syntax). >>- 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. The project tweaks is just the working place for collecting tweaks and defining a common set of rules for their coding style and organisation. Each tweak depends on the scripting language it is written in. CFEngine seems to me (and to the FAI folks) like the most obvious scripting language for writing "intelligent patching" of configuration files. If you have concerns about dependencies for "yet another scripting language" then let's discuss if it is worth the trouble to write shell code to accomplish same intelligence as cfengine has already. CFEngine is a scripting language written explicitly to "massage" configuration files on heterogenous computer systems. It can be used as a daemon as well, but that's irrelevant for use with tweaks, and is not done by default with the Debian package "cfengine". NB! The old cfengine is used, not the newer "cfengine2". Also, mostly to those already familiar with CFEngine, beware that while CFEngine encourages a hierarchical structure of interdependence betwence CFEngine scripts, what is used by FAI and intended as policy for the "tweaks" project is self-contained individual scripts. What FAI classes accomplishes is to cleverly group tweaks. FAI also use CFEngine (and other languages) as interpreter for each individual, self-contained tweak. >>- repackage > > > We all know what this means, way too much work. It solves the > problem, but breaks policy and people's backs. Agreed :-) > There is also the multi-layered configuration approach, which I > believe was discussed in Spain, this too is a good possibility. I haven't investigated CFG or Electra yet, but one thing important to me is wether or not they need adoption by Debian developers or can be applied as a "5th config layer". Personally I do not want a 5th config layer in the long run, but believe it is important for progress: Demonstrate to Debian by working examples why technologies needs adoption. And most importantly we can reach the goals of our pet projects while demoøing instead of having to wait for the adoption to take place. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCklREn7DbMsAkQLgRAjKWAJwN5Vig+sO59cAs2hKNyNH9KS7t4gCdF8Dp JUedKglf27pPmf7saPpKpcg= =rORA -----END PGP SIGNATURE-----
