Re: Caldera installation - something Debian should learn
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
Reply to: