Re: (meta) configuration functionality
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24-05-2005 17:30, Micah Anderson wrote:
> Jonas Smedegaard schrieb am Monday, den 23. May 2005:
>
>
>
>>I believe the goal of CFG is to stay alive and be an extra layer of
>>configuration management, integrated into the whole chain by tha Debian
>>package maintainers, officially hackable by CDD-providers and officially
>>maintainable by local admins. A much nicer goal, but also a more complex
>>one to achieve: It needs to be adopted generally by Debian!
Ok, I put my act together and had a (brief) look at both CFG and
Elektra. I was wrong: CFG is _not_ tightly integrated - it need only be
installed while manipulating config files.
CFG is a "markup language" for existing configuration files, and
front-ends friendly for either end-users or debconf that use this markup
to edit and store config files as expected by each piece of software.
Elektra is an abstraction layer for software to retreive and store
config data in a generic way.
CFG is relatively bloated while running (requires either Xerces XML
library or WBEM daemon), but is applied only as a "looking glass" onto
the config files: It requires no recompilation of the software and
breaks nothing if removed again. By comparison, Elektra is quite
lightweight but is tied to the software itself so requires redesign of
the code and recompilation, and cannot be removed again when applied.
CFG is YaST done right. Elektra is Gconf applied globally.
I agree with Blaine that CFG makes most sense to us standing in the
slipstream of a large distro producing binary packages. We can implement
is ourselves NOW without convincing anyone, and can slowly, one package
maintainer at a time, convince our mother distribution to adopt and
extend our work.
> I believe the goal of Elektra is also to stay alive and be an extra
> layer of configuration management that allows for an arbitrary number
> of additional configuration layers to be inserted or removed (e.g. the
> CDD layer). In Elektra's case it would not be integrated into the
> chain by Debian package maintainers, but by the upstream developers
> (although Debian package maintainers traditionally have held an
> important role of helping move things upstream due to pressure from
> their position and would do so here as well). Having this layer in
> place would give CDD-providers a layer to hack with, as well as local
> admins and users.
>
> Its an ambitious and complex goal, something so ambitious that I
> cannot fathom it happening without there being a coordinated push from
> some place. I see this project as being a potential place where this
> push could come from.
I certainly agree it is ambitious.
How would you push? Setup a huge autobuild-system that rebuilds packages
with Elektra support patched in?
I strongly suggest we instead consider packaging CFG (both WBEM and XML
variants) and start defining CFG profiles for each software package we
want to access more tightly through debconf than the current loose
expressions. It seems only slightly more complex than writing cfengine
tweaks, and the general use is alot more (in addition to programmatical
access to the files you also get GUI access to them!).
- 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
iD8DBQFCk5NUn7DbMsAkQLgRAmpBAJ9g2ZnXT+bfHFkgbOIEFkyDKW+MzgCfTjf9
CVQUzsNsNNzSFpUD5FRfAcE=
=XE56
-----END PGP SIGNATURE-----
Reply to: