Re: automating debconf
On Thu, Feb 22, 2001 at 03:00:59PM +0100, Arthur Korn wrote:
> > ssh -t $HOST '
> > PATH="/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin"
> >
> > dpkg-reconfigure -ftext debconf <<__EOF__
>
> Hmm, I see. You are using the text frontend, and I think it's
> legitimate if this frontend (which is designed to be
> interactive) want's a tty.
no, it's not legitimate to require a tty. it should accept input from
stdin.
if that's not possible for some reason, then there should be a pipe
input method to provide the same functionality without requiring a tty.
such a method could be implemented by modifying the existing "editor"
method as it already does everthing that's needed except that it expects
input from a file rather than stdin.
> Probably you should do your pipe stuff in a seperate frontend
> (-fpipe),
that's precisely what i want. it doesn't exist yet. hopefully it will
exist one day.
> or use the 'noninteractive' frontend and either Joey's backend
> database library or just copy in that config files that you need
> afterwards.
you're confusing front-end with back-end again. i hardly care at all how
or where debconf stores its data, what i care about is how i can get
that data in and out of debconf.
even when the backend db is a standard part of debconf, debconf will
still need a way of inputting data from stdin and a way of outputting
data to stdout in a consistent and usable format.
note that i don't just mean being able to set one option at a time on
a command line, i mean the ability to batch-input a whole bunch of
settings at a time by dumping the list of questions to a text file on
one machine, editing it with vi (or sed or perl or whatever), and then
using that file on dozens of other machines by piping it into debconf's
stdin. for "text file" read as "text file or text stream"
if that's in the plans for debconf, then great! consider this message a
wildly cheering voice of support for such a feature. if it's not in the
plans then this message is a wishlist feature request.
personally, i would have thought that a pipe input/output method would
have been one of the first available for debconf - it's relatively easy
to implement, and it would be extremely useful for automated testing of
debconf itself....script a test suite rather than have to set there and
manually interact with it over and over again.
> I'd do it with 'noninteractive' and copying config files around
> I think ...
the trouble with noninteractive is that it leaves me no control over
what happens. i can't afford to just ignore what debconf-enabled
packages will do to my systems, i need to be able to control it.
for the purpose of doing remote upgrades and installs, i'd like to
be able to just ignore debconf...but i can't because i have no way
of knowing what any particular package is going to do when it gets
upgraded, and no way of knowing what the defaults are going to be - some
will blow away my configuration file and regenerate it from the debconf
backend. that's a bug and a misuse of debconf but it happens, and it's
likely to happen more often in future as debconf becomes more useful and
the temptation to use it instead of text-file configuration (i.e. use it
as a pseudo-registry) increases.
> > it is also necessary - debconf should not destroy useful
> > functionality (e.g. the ability to install/upgrade a package on a
> > remote system using ssh and a script).
>
> It does not!
it does. i've even provided evidence of it doing exactly that,
along with a detailed description of what the problem is and how it
could/should be fixed.
craig
--
craig sanders <cas@taz.net.au>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Reply to: