Re: RFC: Debian Package Configuration Proposal
OK, I posted a proposal for the formats, etc. to debian-devel and
debian-admintool.
On Sun, 26 Jan 1997, Vociferous Mole wrote:
> [So far, Tom's is the only response I've gotten. I therefore assume
> one of the following:
>
> 1. The proposal is blindingly perfect, and everybody agrees.
> 2. The proposal is mind-numbingly stupid, and not worth replying to.
> 3. Everybody is too busy to read and respond 300 line e-mails.
> 4. Nobody cares.
>
> (1) seems unlikely, (2) only slight more likely (Ok, IMHO), and
> (4) is scary. I hope it's (3)....
> ]
>
> On Jan 26, tom@lpsg.demon.co.uk (Tom Lees) wrote:
> > On Thu, 23 Jan 1997, Vociferous Mole wrote:
> > > I. The Goals
> > [snip]
> > > 6. Users don't have to use the tool -- editing the "normal" config
> > > file should have priority.
> > Difficult - we would need to re-merge this info back into the CDB later.
>
> Yep, but there are always going to be situations that a "standard"
> configuration won't solve, and people who would just rather
> do it by hand. My initial idea is that dconfig would (by default)
> refuse to change files that had been edited by hand, and that
> 'HOSTNAME=`cfgtool -r BASE_HOSTNAME`' is pretty easy to
> change to 'HOSTNAME=blah'. Converting back is either
> a matter of re-editing (or more likely, reinstalling), and/or the
> use of '--force' on dconfig.
This sounds like a good compromise.
>
> >
> > > II. The Files
> > [snip]
> > > 3. pkg.postcfg -- A preferably non-interactive script, run after package
> > > installation completes, but before the postinst.
> >
> > I think we should be more specific than preferably non-interactive. Maybe
> > add another which is interactive. That way, we can ensure truly
> > non-interactive configuration. So pkg.postcfg _MUST_ be non-interactive,
> > but if you want to do interactive things here, call it
> > pkg.postcfg.interactive instead.
>
> I originally specified non-interactive, but added the 'preferably'
> to make it easy for packages with complicated postinstalls (eg
> smail) to 'blend in'. I'll try to rephrase to make clear that any
> new pkg.postcfg are to be non-interactive.
>
>
> >
> > >
> > > Why three files? I want the pkg.dbcfg file to deal with the most common
> > > case: the user sets the values of a bunch of variables that are later
> > > accessed from a shell script. I want pkg.cfg to deal with the more
> >
> > Can we do this for perl/emacs/etc., as well (example: innshellvars.*).
>
> Anything that can activate cfgtool and assign the output to a
> variable should be able to do this, and that includes perl and
> emacs. I was trying to distinguish between package configurations
> that could deal with cfgtool directly, and those that need some
> sort of post processing to merge items from the CDB into the actual
> configuration file -- cern-httpd is an example of such a package.
I think there is a major argument against doing this sort of thing. Sed
would be my preffered option, but I think we should make it so that
package maintainers can choose which system they prefer (I like the idea
of using m4 to generate a postcfg which uses sed to merge the values).
> > One point. What do we count as "configuration data"? I would define it to
> > only include data used by the package the configuration script uses. So
> > inetd, etc., still belongs in postinst.
>
> I agree. My definition of "configuration data" is not very good, mostly
> along the lines of "I know it when I see it." A very basic rule would
> be "If you ask the user about it, or expect them to change variable
> definitions in a file, then it's configuration data." Or at least,
> it's configuration data I want to be able to handle with dconfig.
I don't like the idea of complex configuration files being supplanted by
the CDB. Just the basic values in them will be OK, but otherwise this
starts to look like the Win95/NT registry which is/was a complete
disaster.
> > > If they are separated this way, then the first two (.dbdfg and .cfg)
> > > could be kept separate from the package itself. Instead they would
> > > be kept in a file on the server, just as the control information is
> > > kept in the Packages file (let's call it the Configs file for the sake
> > > of argument). When you run the Update step in dselect, it grabs the
> > > Configs file, runs 'dconfig --update-available' to extract them all into
> >
> > Hold on a minute. It already takes long enough to download 800K's worth of
> > package data over my 14.4K modem - unless these are going to be small
> > enough (which I doubt they are), this would seriously make me not consider
> > using dconfig/dselect.
>
> I understand. But I actually don't think it would be all that big --
> most packages *don't* have any configuration data, and many of the
> rest would just have a few variables. I just tarred up my whole
> /etc (including a bunch of X stuff), and the total came to
> about 200K, compressed. It may not be a very good indicator, but
> I would astonished if the actual 'config' information came to
> more than 30K, compressed.
This would be OK. I think we should check that if we preconfig a package,
then the installed version needs to be the same version as the version
preconfigured, or we re-run the configuration steps.
> An alternative would be to have a 'package configuration file' (say
> '.dcf') alongside the .deb files in the archive. Then you would
> only retrieve the ones you needed (via ftp, if necessary), after
> making your selections. My only real objection to this is
> the clutter on the archive site. Maybe they could all be grouped
> under stable/config and unstable/config rather than with the
> binaries, after all, they should be architecture neutral.
It would also make it horribly decentralized. Downloading 200 separate
files that come to 200K is slower than downloading one 200K file, and also
more user-unfriendly.
> As I mentioned earlier, this is the *only* reason I would allow
> .postcfg to be interactive.
Then why not keep it in postinst for the moment, and file bugs against the
offending packages?
> > > I think the easiest way to deal with variables that are shared between
> > > multiple packages (i.e. some of the MTA information) would probably
> > > be to create a 'configuration-only' upon which the other packages
> > > would depend. Most of the truly core values (hostname and domainname,
> > > timezone, etc) would be part of a base config.
> >
> > Not necessarily. If you just put these values in the CDB, then if they are
> > already there, you can use the existing ones.
>
> Yeah, but when you purge a package that uses them, who gets to
> delete them? Tracking multiple references is a real PITA.
It's not too difficult. In my spec, I just said "only package-specific
vars should be deleted". Or we could have a dconfig --cleanout that
removes any variables not currently in use.
> > > III. The dconfig program.
> >
> > If we standardize all this pretty quickly, I can get to work on this. Or
> > should we assign a team of developers?
>
> I'd like to spec out the .dbcfg format, and the basic dconfig architecture
> first (all open to discussion, I'm not trying to dictate, but I don't
> want to spend a bunch of time coding and then discover we've forgotten
> something critical).
OK, I posted a spec - it's open to comment.
> > > 'dconfig pkg' - perform the following steps, in order:
> >
> > > 1. If the pkg.dbcfg exists, read it, and present the values to the user
> > > to be examined/changed. If the variables are already in the CDB, use
> > > the CDB value for the default, otherwise, use the defaults in pkg.cfgdb
> > > (which is never changed, except by a new release of pkg). This tool
> >
> > Or a newer Configure file being installed. Which is a problem. We should
> > probably make sure that for installed packages, this is never updated. (Or
> > maybe installing a package places an 'override' file in /var/lib/...).
>
> Oops, glad you caught this. I think there are two trees -- one for
> installed packages, one for the stuff from the distribution. If you're
> modifying an existing configuration, then you want the version of the config
> files that correspond to that version. If you're upgrading, then you want
> the new ones. After a successful upgrade, you copy the new ones
> into the installed tree. Looks like more options for dconfig.
Have a file /var/lib/dconfig/Configures. This is from the archives. Then,
each installation puts another file in
/var/lib/dconfig/info/blah.{dbcfg,cfg,postcfg}.
> Or, this may be another argument for individual package configuration
> files (.dcf, mention above).
>
> > > dconfig --register pkg <file>
> > > Register <file> as a dconfig configuration file, and generate and
> > > store and md5sum for the file. This is for the case where pkg.postcfg
> > > generates/edits a file based on data in the CDB. If the user then
> > > modifies that file, you want to protect against a later dconfig run
> > > inadvertently overwriting those changes. It would be the responsibility
> > > of the postcfg to register any generated files. This is in *parallel* to
> > > dpkg's conffiles, and may or may not eventually replace it.
> >
> > Maybe we should have a list of these files instead (pkg.dconfig-files),
> > the same way conffiles already does it. This will avoid the extra
> > slowness of running, e.g. 14 copies of this.
>
> But you still have to generate the md5sum after the .postcfg has run.
> And it's not actually that many packages -- only the ones with a postcfg
> that creates/manipulates a files. Most of the files that are now
> dpkg conffiles remain dpkg conffiles -- dconfig never touches them.
OK, fine. From some code I hacked together today, it's actually very fast
to do this. I just forgot that dpkg (stupidly) reads the entire database
when it doesn't need to, which slows it down seriously.
> > Could you clarify this - can this be an xterm? Can we use ncurses (like
> > dselect)?
>
> Definitely. It just can't require X or svgalib -- it's got to be
> runnable during a base install, and immediately after.
OK, that's in the spec.
>
> > I think scripts should have the values inserted by sed, i.e.
> >
> > HOSTNAME=blah ## __DCONFIG__HOSTNAME__
> >
> > Then do a sed -e 's/^[^# ]\+\([ ]\+##
> > __DCONFIG__HOSTNAME__.*\)$/HOSTNAME="`cfgtool -get basecfg_HOSTNAME`"\1/g'
> > to the script (maybe perl is more suited to this).
> >
> > Then the user can EASILY see how to edit the scripts values, and the
> > automatic tool/user combination can be managed fairly easily - just run a
> > dconfig --update-all to set back to the CFGDB/update from the CFGDB
> > (warnings would appear if the md5sum didn't match).
>
> My problem with this is that every package that uses dconfig now
> *requires* a .postcfg, or that dconfig track and manipulate a lot of
> files in a rather scary way. With my approach, the maintainer gets the
> (fairly simple, I think) cfgtool references right (whether shell script,
> or perl, or emacs), and it never gets touched, unless the user modifies
> it. With sed, either the maintainer has to get a bunch of sed scripts
> right (harder, in my experience), or dconfig applies sed
> scripts to arbitrary files, which I think is a Bad Idea.
If you use m4 to generate _WORKING_ sed scripts, the first is not a
problem. Reading the value directly from the CDB should be an option left
to the maintainer, with one exception: /etc/init.d/<blah>, and
/etc/rc.boot/<blah>. Since not all partitions may be up at this point, and
cfgtool may not work, usage of SED to do it is REQUIRED.
> As for the user editing, I think a simple statement that says "anywhere
> you see `cfgtool -get <something>` (or its equivalent in perl or emacs),
> you can put in your own value" is pretty straight forward.
That's assuming the user can find and read this relavant README. Not all
users do this. Newbies to UNIX may be totally confused by perl equivalents
of this :)
> > > User's may opt out of dconfig by editing the actual configuration
> > > file by hand, so long as it is registered with dconfig. There should
> > > also be a dconfig option to get it back under dconfig.
Another point - does that mean we need a copy of the original somewhere
in case the user edits it out of all recognition?
--
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: