Interactive installation [was Re: Caldera installation...]
I'm repeating all the text of the previous message, because it seemed to
have got lost in the futile thread about text config files. It's only
by luck that I didn't delete it without reading it.
"James R. Van Zandt" wrote:
>
>R Garth Wood <rgwood@peace.netnation.com> writes:
>>On 21 Apr 1999, Steve Dunham wrote:
>>> "Brimhall, GeoffreyX L" <geoffreyx.l.brimhall@intel.com> writes:
>>>
>>> > I think the case can be made that for novice users they don't
>>> > need to interact with the dpkg install questions.
>>>
>>> Yup, this is the biggest problem with Debian - and it is why I'm
>>> very surprised that Corel chose to base their distro on Debian.
>>> IMHO, Debian is a very poor choice to base a "user friendly"
>>> installation on, because you would have to rewrite the install
>>> scripts of half of the packages.
>>
>>I second that motion. We are working on a distribution based on
>>debian as well. Debian needs a grace full way to have packages
>>indicate that they need intervension before they are
>>configured. Anyone?
>
>I think it will have to be the other way around: packages should
>indicate that they do *not* have interactive configurations.
>I propose this be done with a new field in the control file:
>
> `Interaction'
>
> This field appears in the control file of a binary package. The
> value is a list of alternative methods, separated by vertical bar
> symbols `|' (pipe symbols). Predefined methods are:
>
> `none'
> None of the pre- or post- scripts require user input.
> `std'
> The pre- and/or post- scripts write queries to stdout, and
> expect to read answers from stdin.
> `delayed'
> postinst can be run arbitrarily long after package
> installation, and prerm can be run arbitrarily long before
> package removal. In the interim, the package would be
> considered unconfigured but usable. For example, a daemon
> from a previous version package will continue to run (e.g.
> it would not try to read an incompatible configuration
> file). Another package that pre-depends on this one must
> be able to configure itself. `delayed' implies `std' as
> well.
>
>
>Our near-term goal should be to add "Interaction: none" to control
>files wherever appropriate. I expect that debhelper would be made
>smart enough to do that automatically for most packages (those with no
>scripts, or scripts with only clauses generated by debhelper scripts,
>to register for menus and such). As soon as a substantial number of
>packages are marked this way, we can for example implement a signal in
>apt to tell whether the selected packages can all be installed without
>user interaction.
>
>
>Our mid-term goal should be to implement some non-interactive method,
>such as:
>
> `acap'
> Retrieves configuration information from an ACAT server (see
> RFC 2244).
>
> `ldap'
> Retrieves configuration information from an LDAP server (see
> RFC 1823, 2307, etc.)
>
> `xml'
> Obtains configuration information by parsing an XML file.
>
> `sql'
> Obtains configuration information from a database.
>
>et cetera.
>
>
>Our long-term goal should be to convert as many packages as possible
>to use the chosen non-interactive method. `std' should also be
>supported as a fall-back. Eventually, we would have mostly
> Interaction: none
>with a modest number of
> Interaction: std|acap
>
>
>Would this have to be part of Policy, or would we just need a change
>in the Packaging Manual?
>
> - Jim Van Zandt
I think it ought to be policy; though not until the mechanism to support
non-interactive methods has been put in place.
We need:
1) a tool to let {pre,post}inst scripts get arbitrary data
2) an indication of which packages use this
3) an indication of which packages need some other action taken before
they can be operational, and in what circumstances
For example, postgresql needs a datum (whether dates should be in
American or European format) which it gets from a pre-existing configuration
file or else from stdin. Postgresql may also need a database dump and
reinstall to be done (when there is a major version change) - this is not
done in postinst but left to the administrator to do later. For this
package, both (2) and (3) would be true.
In the postinst, I currently prompt for the date setting and read the
response. I should like instead to say
response=`dpkg-query package question`
dpkg-query should search its (text) database for package,question
and return the stored response; if nothing is stored, it should prompt
the user with the question and store and return the response.
Additional options to dpkg-query should enable it to extract data from
the various other sources you mention (ldap, xml, sql, ...) or from
internationalised question databases.
An administrator who is updating or installing packages will know (from
the Interaction: field) that postgresql needs input; he can examine the
question database to see if it needs fixing in advance. He will also
be able to see that an upgrade from 6.3 to 6.4 will need a database
rebuild, that cannot be automated.
We probably need another tool to go through a package's questions and
collect the necessary answers.
Problems:
packages that change their questions according to circumstances
may be a difficulty
I made similar suggestions a year or more ago. Ian Jackson specified a
list of things to make it much more rigorous, which were beyond my
ability, so I left the matter. Since nothing at all has happened since,
I propose we implement this crude scheme and let the perfectionists replace
it later, if they ever get round to it.
Is anyone else interested in working this out?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Nay, in all these things we are more than conquerors
through him that loved us." Romans 8:37
Reply to: