[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: automating debconf



On Sat, Feb 24, 2001 at 12:20:57AM -0600, Scott Dier wrote:
> * Craig Sanders <cas@taz.net.au> [010222 19:13]:
> > 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.
> 
> [...]
> Having i/o like you suggest is a neat idea, 

yes, it is. it's also an obvious idea which has been used over and over
again throughout the history of unix because it is a fundamental part of
the "unix way of doing things".

> but it wouldn't be a 'real' solution, 

it's a "real solution" for the task at hand, which is getting data into
and out of debconf in an easily-scriptable manner.

> just a conduit for people to hack at to setup unattented installs.

DOH!  that's exactly what i want.

> Having the db method really feels like the right way to go.

i'm getting really tired of people confusing the two things. 

it's tedious and annoying to be talking about front-end issues and have
others continually respond as if i'm talking about back-end issues. i am
not and have not been talking about backend issues at all. this thread
is solely about front-end issues.


the backend db is still a damn good idea.

being able to use a pipe as a "front-end" I/O method is a COMPLETELY
DIFFERENT AND SEPARATE IDEA, TOTALLY UNRELATED.

joey's db backend is a backend.  a pipe I/O method is a front-end.

can you spot the difference?


the main point of having a separated and modular "frontend" and
"backend" to any process is so that you can choose from multiple
different front-ends and back-ends. pick the one(s) that suit your needs
at this moment in time. if you're at the console, then use a dialog or
slang or gnome front end. if you're working on an automation script,
then use the pipe front-end. if you like text file databases then use
the flat text file db backend, if you like postgres or mysql then use
the postgres or mysql backend. mix and match to suit your needs.

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: