On Mon, Dec 21, 1998 at 02:01:14PM -0500, Brian Ristuccia wrote:
> I haven't been completely following the discussion since it moved off debian
> private, and just subscribed to this list a few minutes ago, so bear with me
> if I propose something that's already been proposed or ruled out as
> impractical.
AOL :) I am new to this list but I really want to have something in place. And
that fast...
> What I propose:
>
> A scheme for configuring packages to be installed all at one time, either
> before or after installation, with configuration questions answered
> manually or automatically from a stored template.
I think we should solve this issue for one and ever.
> How I think it might be implemented:
>
> If a package is capable of what I'm calling "interact before/after"
> installation, an additional file in control.tar.gz called options would be
> present. When run, it would produce a list of option names, their
> descriptions, reasonable defaults, and possible values on standard output.
> The list of possible values could indicate that the configuration option is
> a yes/no question, or that text matching a certain regular expression is
> required, is numeric, a list to choose from (eth0, eth1, etc.) or is perhaps
> some other data type.
Nice idea. I think we should have configuration packages which provide methods
to configure that stuff. Consider a package netconfig for example which would
query the type of network using nice looking dialogs, ... :)
Just a though. I think we should enter brainstorming mode for a while :)
> When it's time for the user to configure the packages, the package manager
> frontend would run this file and present its output to the user in a manner
> appropriate for their display. For example, yes/no questions and prompts for
> text on a dumb terminal, a dialog box with check boxes and text fields on an
I think we have to think about this for a period. Let's set some goals:
- we should NOT require the packages for graphical configuration
- we should NOT require complicated tools to read the configuration
(complicated = perl/awk for example)
- we need some kind of repository which can be read by the shell
> X terminal. Any options the user sets would be placed into environment
> variables of the same name (perhaps OPTION_IFACE=eth0, or whatever.) Perhaps
> the options script could be called with these environment variables set and
> report an error if conflicting options are enabled or some other error state
Environment-Variables? Oh no, nothing for me :) I think a script get_option
... would be nice. What do you think?
> has occured. The values used could be saved somewhere, (perhaps as a shell
> script) and could be fed into subsequent installations on other machines so
> that the questions do not have to be answered again.
Another goal (at least for me):
- it should be possible to use some kind of network repository
- we need to flag local configuration switches (for example hostname, ip)
- it should be possible to acquire the options from a script which the
sysadmin can write
> When the package manager frontend goes to run the package's preinst,
> postinst, etc. files, it would set the environment variable NON_INTERACTIVE.
Umm - really? Okay, why not. I mean to remember a better idea (someone
proposed something else), but it won't come to mind :(
> It would also set the options up in environment variables. The
> preinst/postinst script would be able to look at these variables instead of
> prompting the user if they are set. Otherwise, it could default to the old
This might work for simple stuff but if it starts to get complicated?
Remember: we have to be able to configure the whole system automatically.
> way of asking questions to prevent the package from breaking when installed
> with tools that don't support the noninteractive functionality.
Yes.
> If there's interest, perhaps I'll work up a mock version of a package like
> dhcpcd or something so people can get a better idea. I belive this sort of
> thing can be done without any changes to dpkg, and without making the new
> packages incompatible with existing package managers.
I vote for further discussion (*duck*). I think we will need to update dpkg.
And it would be really nice to send informational output (stuff like "fdformat
is now superformat") somewhere where you can read it later or automatically
send it to another command. I am thinking about doing a heterogenous install
in a network where the set of installed packages differs from host to host. It
would be great if you could archive this informational messages and send them
to the server for example. But I do not want to read the same message (if a
package gets installed on each host) again and again. Then I could write a
script which decides based on a checksum or the packagename-version pair for
example if I got this text already.
Sorry for this being not thought out very well but I do not have the time
currently.
cu
Torsten
Attachment:
pgpKD_3ZnZ7d4.pgp
Description: PGP signature