Re: PROPOSAL: Dconfig standard
On Wed, 29 Jan 1997, Steve Greenland wrote:
>
> > ============
> > 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.
This is OK if shared variables come from a shared package.
>
> >
> > * 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.
Right. But I think we might need a new section ("configs"?) for these
packages (since, e.g. emacs is under editors, even though it provides
MUA functions - confusing if emacs requires a config package from mail).
>
> > 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.
OK. I'll remove this from the spec.
> > * Range - supports the following formats for numeric types:-
> >
> > * 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.
This is a great idea. I'll keep some types though, to improve speed for
basic things like "Description of your organization".
> Basically, the range check would require that the Perl expression
> return "True".
Hmmm... can I just do something like "VALUE=balh perl <range>", and check
the return value. I haven't taken the time to learn how to program perl,
only how to hack it :) Please can someone help me out as to what
command-line/file I should pass it.
> 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
I like this idea a lot. I'll add it to the specs file.
>
> > 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?
This is good, seeing as we can also take the default for one variable from
another using perl (so if someone wants a more restricted version, they
can specify the default to check the real variable, then put their
restrictions in range - the other restrictions are already checked on the
other package).
> > 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.
Dconfig does know them - they are registered with it. The idea being that
the user can tell dconfig individually (per file) which of the conffiles
he/she has modified manually should be set back from the CDB.
> (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.)
OK - we use `blah` to do it. This looks fine at the moment. However, this
is still for files like /etc/httpd/httpd.conf, for example.
> > 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).
OK.. We check conffiles as the first step.
However, we should tell the script per-file which ones the user wants it
to update. We could prompt the user with a "Yes/No/All" for the answer to
"Update this file even though you have modified it?".
> > 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.
OK. This will go into the standards document.
[about `blah` in shell-script files]
> 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_.
OK. So we must make sure that cfgtool in /sbin, the CFGDB in /etc. and so
on, in case /usr is net-mounted, or otherwise inaccessible at boot-time.
> 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).
Agreed.
> 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'>
OK. This is neater. What I did intend was for the case of sharable
variables.
[dpkg --purge, etc]
>
> 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.
Fine. I'll repost the standards as updated.
--
Tom Lees <tom@lpsg.demon.co.uk> http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)
--
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: