Re: PROPOSAL: automatic installation and configuration
Torsten Landschoff <firstname.lastname@example.org> writes:
> While I like to overall idea there are some problems with your proposal. This
> utility you suggested would work just fine but it has a few issues for future
> extensions. For example I dream of a Debian installation which asks the
> configure questions while downloading the packages.
Have you read my proposal about better configuration of debian
packages? My proposal states that not only all questions must be
capsulated behind an api, butalso other interactions, like running
other programs or testing whether files exists and so on. That way you
can configure any package more or less with only the configure script
at hand, so you can configure during download, once you got that far.
But mainly that is a problem with dpkg/apt. They must allow for
configuration during download and unpacking. Lets see what the rewite
of dpkg will bring.
> But shell/perl scripts are not that easy to parse to support that. I would
With certain restrictions shell scripts are easy to parse. You can
overload the api command to ask questions with one that actually
output another shellscript that will display a menu with whiptail or
parse the script into a tcl menu, just like the kernel source can do.
> like to suggest just giving the name of the variable to dpkg-getconfig with
> /var/config/<package> or something telling the program about the possible
> variables. dpkg-source should be enhanced to support putting another file into
> the .deb named config.
But you need dependencies between those variables. e.g. you don't want
to get questions about your IP, your gateway, your DNS and so on if
you don't have a network. You need some scripts for that an shell
scripts are easiest to understand, maintain and test.
> A new generation of dpkg or apt could support reading the information in this
> file to ask the questions premature to the installation. It will need to get
> before the data.tar.gz into the deb though.
I haven't suggested to put the config scripts into the control.tar.gz
file, but thats where it eventually should end up. And then it would
be before the data.tar.gz.
> In fact I was working on just another configuration system but I did not make
> it to the coding phase - it would support moving the native configuration of a
> program to this library.
> I do not want to put my project in favor but as it would be more powerful we
> might want to support it one day - when it is ready ;-)
> Massimo, I greatly appreciate your efforts. If you have the time go ahead and
> implement your system. If it gets adopted I would like to help converting
> packages. I just do not want to let my idea die - I will show some code when I
> have it ready.
Whats your idea? Give us some concepts and designs you are thinking
about, before Massimo and I have all our code written up. Its easier
to incorporate ideas now.
May the Source be with you.