The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "autoinstall" with debian



On Tue, 5 Nov 1996, Philip Hands wrote:

> > IE, I'm needing to install (under /a) some packages that have
> > interactive postconfiguration, and I need to do this all
> > noninteractively.  Barring getting a non-interactive postconfig for
> > every package (my preference, but not necessarily realistic in a
> > shortish time frame) I'd like to just --extract these, configure
> > them with a locally-provided script, and "do the magic" to tell
> > debian the packages have been configured.  What is "that magic"?
>
> Something that might be worth considering is to use the same approach
> as the SVR4 package system.
>
> What happens is that there is only one script per package that
> is allowed to interact with the user, and it puts all the users
> selections in a file that is then used by all other scripts to allow
> them to be non-interactive.  The response file is also saved with the
> other package info files.

__   __  _____   ____    _ 
\ \ / / | ____| / ___|  | |
 \ V /  |  _|   \___ \  | |
  | |   | |___   ___) | |_|
  |_|   |_____| |____/  (_)
                           

perfect solution - solves auto-installation, auto-update, and provides
the config database which a lot of people want.

The hard work now is to define the standard for the config database and
how to interact with it.

> It is a little more effort initially because you have to separate the
> interactive parts from the scripts that actually do the work, but has
> several advantages:
>
>   o You can prepare a set of response files in advance (e.g. by using
>     the ones from a previous install) and do a non-interactive clone
>     install easily

very useful, especially if configuring a lot of machines which are all
basically the same (only hostname & ip address differ).

the set of response files could even be made into a debian package - just
install with dpkg BEFORE running dselect to install the system.

if all the response files are kept in a known locations (e.g.
/etc/config or /etc/defaults) then it would be trivial to write a script
which bundled them all up into a package.




a set of standard variables (both required and optional) which were
common in all response files would be useful too.  Some that i can think
of off the top of my head:

RUN_AT_BOOT=[yes|no]
BOOT_MESSAGE="message to print at boot time"   (e.g. "Starting NFS services")
BOOT_OPTIONS=[command line options]

>   o When upgrading, the options used for installing the previous
>     version can be used as this one's defaults
>
>   o When removing packages, the options selected at installation can
>     be used to help decide what needs to be done.

> The trouble is that any change like this would require every package
> to be changed in order to be worthwhile.

not necessarily.  as long as the method chosen is optional (but strongly
recommended - initially, maybe switch to making it mandatory in 6 or 12
months) then existing packages can gradually switch over to the new install
script standard

Craig

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com