Re: PROPOSAL: Dconfig standard
> ============
> 1. pkg.dbcfg
> ============
I generally agree with the syntax -- stick with something that
works.
However, I think that variables belong to a package. Therefore,
Item: name
is sufficient. The actual variable name in the CDB will
pkg.name.
>
> * Section - The following sections are currently defined:-
Unnecessary, given the above (but see comments under 5).
> Virtual package names can also be used (e.g.
> "HTTPd" for values common to all [or at least most] http servers).
Thus, a base-httpd package that supplies only configuration
information. All the other httpd's would depend on this. This
is not a good place for virtual packages.
> Note that capitalization _DOES_ matter for all fields, so virtual package
> maintainers should standardize on the capitalization that should be used
> for each virtual package.
ACKK! Making these variables case sensitive is just asking for trouble.
They should be stored in the CDB in standard form (e.g. all caps), but
any reference should work regardless of case. It's going to be hard enough
for people to get the spelling consistent.
> * Type - The following types are defined:-
>
> - bool - `yes'/`no'
> - string - A string
> - int - An integer
Consider adding enum (string with predefined choices), but see
also comments on range and default value.
> * Range - supports the following formats for numeric types:-
>
> x-y - Between x and y
> <n - Less than n
> >n - Greater than n
> [x,y,z] - Only x, y, and z
> [^x,y,z] - Anything but x, y, or z
>
> * Default - obviously, a default (sane) value for this. Don't specify if
> it's something like hostname, IP, etc. Dconfig will choke on having no
> default if it is told to not ask the user, and the package will be left
> unconfigured.
This is more or less my original thought, but yesterday I had an
epiphany: make them Perl expressions. Then for Range, I can
express something like (\d{1,3}\.){3}\d{1,3}, which (if you're not
up on your Perl regex's) is 1 to 3 digits, followed by a '.', repeated
3 times, followed 1 to 3 digits. In other words, an IP address.
Basically, the range check would require that the Perl expression
return "True".
Likewise, the default could be a Perl expression, including references
to other configuration values -- this would almost eliminate the
the need for most packages to use pkg.cfg
> NOTE: Multiple packages supplying the same value
>
> If more than one package provides the same value, they should try to
> standardize the description and types of values they demand. The last instance
> of the section will be used. If they must use, e.g. different ranges, then
> they should be probably use variables in their own sections.
Letting multiple packages use the same value *requires* that you
keep track of which packages are using each and every variable. It also
leads to user confusion ("Why is package y prompting me for hostname, didn't
package x just ask me for that?"), and maintainer confusion ("If I change
the range on this, who do I break?")
Yes, you can work around these problems, but they are work. Making a few
'vpkgcfg' type packages is much easier. After all, how many would you
really need? Basecfg, netcfg, mtacfg (maybe), httpdcfg?
> ==========
> 2. pkg.cfg
> ==========
>
> 2. pkg.cfg -- An interactive script. This script would be run
> after after pkg.dbcfg, if pkg.dbcfg exists. Pkg.cfg may use any tools on
> the base system -- {ba}sh scripts, grep, awk, sed, and perl-base, etc.
> -- basically, whatever a preinst or postrm script might use. It may not
> assume that any part of pkg is available. However, the only thing
> that this script may change is the CDB; no file editing/generation,
> etc.
>
> Here are some additional clarifications:-
>
> * It should definitely _NOT_ require that it is running on any particular
> terminal - certainly _NOT_ that it is on a utmp-identified one (major
> dpkg bug with this). This should ensure that ptys can be used by an X11
> configuration program which uses its own builtin terminal (would look nicer
> than an xterm, and be less prone to failure).
> * Maintainers really should try not to supply a pkg.cfg unless it really is
> necessary (often postinst or preinst will do instead).
Good, but moving stuff into postinst or preinst is probably not the
answer. Needs to be a clear distinction between "install" stuff
and "config" stuff. Remember, dconfig <pkg> *wont* run any of
{pre,post}{inst,rem}.
> ======================================
> 3. pkg.postcfg/pkg.postcfg.interactive
> ======================================
>
> >From the original RFC:-
>
> 3. pkg.postcfg -- A preferably non-interactive script, run after package
> installation completes, but before the postinst.
>
> These files should be installed by the package into /var/lib/dconfig/info.
> pkg.postcfg _MUST_ be non-interactive - if you need to use an interactive
> script for this, call it pkg.postcfg.interactive.
>
> pkg.postcfg will be called with the arguments a list of the conffiles it
> should update (see section 4).
Who provides these arguments? Dconfig doesn't know them. Pkg.postcfg
*knows* which packages it's upgrading - it doesn't need to be told.
(Actually, I see below how you're determining that, and it's based
on the idea that *all* packages with configuration data run sed
against their dconfig-conffiles, which used to be dpkg-conffiles.
I disagree *strongly* with this -- see below.)
> ====================
> 4. Dconfig Conffiles
> ====================
>
> NOTE: Is there a better name for this? (i.e. does it get confusing between
> dpkg's conffiles and dconfig's conffiles).
>
> Conffiles can be registered in one of two ways for a package.
>
> 1. By the postcfg running dconfig --register <pkg> <files> after
> having inserted configuration values into them.
> 2. By supplying a file /var/lib/dconfig/info/pkg.conffiles, which
> will automatically be reregistered every time after the postcfg
> is run.
>
> For both methods, the registered md5sums are checked before the postcfg is run
> again, and if they are different (i.e. if the user has edited the file, not
> the CDB), the user will be prompted whether to update from the CDB, or not
> modify that file. This is why the list of files to update is supplied on the
> commandline of the pkg.postcfg script.
No, dconfig needs to check the md5sum before it even begins prompting
for data. If the user has edited any of the registered files associated
with a package, then dconfig either aborts (unless invoked with '--force')
or asks about enabling '--force' (which would be nice when called
from dselect).
> Note that probably the best way to generate pkg.postcfg files is with m4 (as
> GNU autoconf does to generate configure scripts). I have hacked together a
> couple of m4 macro-files which enable a postcfg to be genrated fairly easily.
> However, they still generate very inefficient code :(.
I think this is useful, but am against it as the general case. Packages
whose "conf files" (in the dpkg sense) are executable (many) should not
require any editing to see changes in the CDB.
> ==========
> 5. The CDB
> ==========
>
> Since the plan I have outlined above does not require putting `blah` all over
> the shell scripts
To reiterate (ad nauseam, no doubt), I believe `blah` is in fact the
easiest, most obvious way for conffiles to interact with the CDB. It
is makes it very clear that the item is coming from the CDB, and requires
no special handling (i.e. pkg.postcfg). It's very easy to see
how to modify it (either run dconfig, or just hardcode the
new value. Without meaning to sneer, if the sysadmin cannot figure
"hostname `dconfig --get basecfg.hostname`" into "hostname cladius",
then that sysadmin _should_not_be_editing_that_file_.
> does not add dozens of tiny little scripts, and does not
> look too difficult for newbie (to Debian), or, more likely, experienced
> sysadmins to modify _WITHOUT_ using the supplied UI. This addresses all the
> concerns that have been expressed by others. It also unifies the interface
> for storing values shared among packages, which is a Good Thing.
Again: packages can use values managed by other packages. Packages
should *not* share values (i.e. a given variable should appear in
one and only one package.dbcfg).
> The best way to partition the CDB is hierarchical, so that it is (fairly)
> easy to browse. I suggest that we follow the lead of menu, and adopt the
> idea of using slashes to delimit the hierarchical classifications, e.g.
> /admin/mail/mailname.
>
> Here is my list for the basic level of the hierarchy possible:-
>
> /local - Values that should not be transported between systems:
> use as sparingly as possible!
> /admin/mail - MTA stuff
> /admin/news - NTS stuff
> /admin/<pkg> - Non-transient info specific to <pkg> (use discouraged)
> /admin/<vpkg> - Non-transient info specific to most or all providers of
> <vpkg> (use discouraged)
> /<pkg> - Config info specific to <pkg>
> /<virtual-pkg> - Config info specific to all (or at least most) packages
> providing <virtual-pkg>
You've got at least three orthogonal ideas incorporated there:
1. local vs shared
2. functional classification
3. ownership (packages)
If you're going to incorporate all of this (and I think we need
1 and 3, and could live without 2), then you need the following three
fields in your pkg.dbcfg.
Package: (Actually, this is inherent in the name, and doesn't really
need to be a specific field).
Section: admin/mail (for example)
Scope: <one of 'local' or 'shared'>
> ================
> 6. Miscellaneous
> ================
>
> - dpkg --purge vs. dpkg --remove, and their respective effects on the CDB
>
> dpkg --purge should remove the tree /<pkg> from the CDB, which dpkg
> --remove should not do.
>
> dpkg --purge should remove the tree /<virtual-pkg> from the CDB if
> this is the last instance of <virtual-pkg> being removed, and all
> of the packages providing it are purged, not just removed.
>
> NOTE: This should not be done by a special postrm, but by dpkg itself,
> when the upgrade to dconfig integration is done.
>
> Variables outside this tree should never be purged unless specifically
> requested by the user. This means that, even if someone removes all
> MTAs (say, when upgrading MTA), the MTA parameters (like mailname)
> are not lost.
While I agree with these affects, I probably disagree with implementation:
simply provide a 'dconfig --purge pkg' command, that reads the (installed
version) of the pkg.cfgdb and clears any variables mentioned there.
It also removes any dconfig-registered files.
Steve Greenland
--
The Mole - I think, therefore I scream
"It's not my planet, Monkey Boy!"
[John BigBoote (Big-Boot-tay) in _Buckaroo_Banzai_]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: