Re: Interactive installation [was Re: Caldera installation...]
psu25682@odin.cc.pdx.edu (Karl M. Hegbloom) writes:
> >>>>> "Oliver" == Oliver Elphick <olly@lfix.co.uk> writes:
>
> Oliver> We need:
>
> Oliver> 1) a tool to let {pre,post}inst scripts get arbitrary data
>
> Oliver> In the postinst, I currently prompt for the date setting
> Oliver> and read the response. I should like instead to say
>
> Oliver> response=`dpkg-query package question`
Please subscribe to debian-admintool and read the log of that list.
I'm currently writing a proposal and deb packages to go along
implementing your idea together with several orthers mentioned on
debian-admintools.
The base idea is to resrict all user interactions to one interface,
namely "dpkg-question". The basic syntax is
dpkg-question question-ID level default --type parameters
dpkg-question knows several types of questions like yes/no, multiple
choise,... Also it can decide not to ask the user when the level is to
high or allways look into a database first and so on.
> Oliver> dpkg-query should search its (text) database for
> Oliver> package,question and return the stored response; if
> Oliver> nothing is stored, it should prompt the user with the
> Oliver> question and store and return the response.
The database is of the form 'question-id="value"' and is a valid shell
script. The user, if he is asked, is presented with the aktual
question, the last answere and the package default. Just pressing
return takes the previous answere.
> Oliver> Additional options to dpkg-query should enable it to
> Oliver> extract data from the various other sources you mention
> Oliver> (ldap, xml, sql, ...) or from internationalised question
> Oliver> databases.
You can overload the functions that extract and write data to the
database file. For example my qvwm package extracts from and writes to
the system.qvwmrc file to configure the window manager.
> It could connect to an `apt' frontend, or to a dialog thing, and use
> a GUI to get the response from the user also, couldn't it? Isn't
> that the sort of thing that CORBA or a message bus like koalatalk is
> meant for?
My implementation is fully executable without any additional gui. In
the case that no preconfiguration or gui is used, the questions will
just pop up one after another similar to "make config" for the kernel,
BUT you can pre or post process the config files and generate menus on
the fly. Thats similar to "make menuconfig" and "make xconfig" in the
kernel source. That would work via a seperate gui, that is purley
optional. Unlike other configure programms, it doesn't need to go that
way.
Have a look at debian-policy during the next days, my proposal should
come up there any day now.
May the Source be with you.
Goswin
Reply to: