Re: RFC: Debian Package Configuration Proposal
On Jan 28, tom@lpsg.demon.co.uk (Tom Lees) wrote:
> > 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).
Certainly, the package maintainer can do what is necessary to
get there stuff to work, including opting out of dconfig entirely,
but we should encourage a certain style.
> 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.
Absolutely. Stuff that is now be prompted for in postinsts, or
basic config programs like smailconfig and httpdconfig is a good
candidate.
> 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.
Good point.
> 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.
The advantage would be that you'd only download the ones
you needed. I'm not a real fan of this, though. Let's try it
with one central file.
Re: interactive postcfgs for packages with existing standalone config
programs
> Then why not keep it in postinst for the moment, and file bugs against the
> offending packages?
Solely so that 'dconfig pkg' has the expected result. It may not
be a big deal.
> > 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.
But then you have track which packages are using which variables.
Certainly it's doable, but what's the real advantage over requiring
that a variable is 'owned' by a certain package, and then having
a few config only packages, and packages that use those variables
depend on those packages?
>
> 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}.
Well, I'd split the Configures file from the archives into individual
files, so that I don't have to read the whole thing every time we
want to configure one package. Perhaps
/var/lib/dconfig/info/installed/pkg.{...} # installed version
and
/var/lib/dcofing/info/available/pkg.{...} # from the archives
Whatever....
> 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.
Everything required to obtain a value from the CDB will be available
on the root partition. Sed is NOT required.
(I'm beginning to think this may be a religious issue.)
> > 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 :)
Examples, examples, examples. If they can't find and read the
basic system documentation (this would go in the (discussed but
as far as I know not published) Debian Sysadmin Guide), then they
shouldn't be mucking around in the config files anyway.
> Another point - does that mean we need a copy of the original somewhere
> in case the user edits it out of all recognition?
Ennh. Maybe. It actually wouldn't be that hard to do (just make
a compressed copy as part of the --register step), and has some
real value.
Steve
--
The Mole - I think, therefore I scream
"A power so great, it can only be used for Good or Evil!"
[Frank Acme Jr., in The Firesign Theatre's alblum "The Giant Rat of
Summatra"]
--
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: