On Wed, Dec 16, 1998 at 12:09:29AM +0100, Wichert Akkerman wrote:
[a lot more than what I'm quoting below]
> Configuration Management
> revision 5
>
> Install-time configuration
> ==========================
>
>We want to make a package which does not break older dpkg's, and we want to be
>able to get the configuration information before the package is unpacked. To do
>this we add a new file, config.tar.gz, to the package besides the current
>control.tar.gz and data.tar.gz . Since all installation-software (apt, dselect,
>dpkg) download the package before installing it, we can extract this before the
>package is unpacked.
Hmmm. This breaks an installation into three stages:
select packages -> download -> configure -> install -> use
or (for multi-machine installs)
select packages -> download -> configure -> download + install
-> download + install
-> download + install
This makes it something of a pain if you're running low on disk space
and can't do an entire dist-upgrade in one go (ie, you can download
1/3 of the .debs, install, download the next 1/3, install, and download
the last 1/3 and install, but only if you rm the downloaded .debs after
you're finished.
Is there any way (reasonable) way of improving the situation for them?
Would it be possible to include, say, an archive of all packages
config.tar.gz's (which would presumably not be overly large) download
that, select the packages you want to install, and then download all
the .debs.
>Since older dpkg's will not process the extra file, we
>can do to things: either create an extra assertion "--assert-configmodule" in
^ (w)
>dpkg which is checked in the preinst, or up the versionnumber of the package.
...and presumably have all packages using the config.tgz (pre-?)depend
on the bumped dpkg?
This will presumably do ugly things to all our dependencies, but I take
it we don't get too much choice in that matter.
Should all packages just cope if dpkg doesn't support the config database,
or will some just cope, and others pre-depend, or fail their preinst,
or...?
>2. The configmodule do
>The configuration module is a executable named `config' in the config.tar.gz
>file. The configmodule is the part of a package that will determine the
>configuration before the package is installed. This means it is run _before_
>the preinst, and before the package is unpacked! Unless pre-depends are
>used, this will mean that the module can only assume the base-system is
>installed.
If pre-depends are done before configuration, this could leave problems
in the event of multi-machine installs still -- it becomes a cycle,
albeit probably a short one. It also makes the "download an archive of
all config.tar.gz's" suggestion above not particularly workable.
Is this avoidable? Will things become really ungainly if the package
has to be configured *before* being unpacked (or *anything* other than
the base system is unpacked)? This still leaves us with sed and mawk,
but drops out flex, bison, and stuff like that.
>5. The frontend
>There are two types of frontends possible: interactive and non-interactive.
>Interactive frontends allow the user to answers questions and see messages.
>Non-interactive frontends get all information from a database (SQL, LDAP,
>db, textfiles, etc.). If a non-interactive frontend is used and the
>configmodule refuses to accept the information the frontend retrieves, it can
>exit with a non-zero exit code, indicating to dpkg it's not possible to install
>the package with the current configurationdatabase.
Should the preinst/postinst also check for these cases? In particular, it
seems like it might not be totally unreasonable to not entirely configure
a package (or perhaps not correctly), but still let it get installed, and
left as unconfigured.
> 6. Communication language
> This communication between the frontend and the configmodule should be as
> simple as possible. Since most IO implementations default to line-buffered O,
> so we use a simple language where each command is exactly one line. A
> prelimary list of commands is:
Are there any example scripts available?
I'm a little disinclined to trust a language that's never had a program
written in it; and in particular, it sounds like the confmodule has to
have a fair degree of intelligence about it. (am i interactive? then
ask these questions? oh, the user answered no? then skip these. ask
these too...)
Is there any possibility of using the work that's been put into the
Linux kernel configuration here? Are there things we want to do that
they haven't already done?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``Like the ski resort of girls looking for husbands and husbands looking
for girls, the situation is not as symmetrical as it might seem.''
Attachment:
pgpK3RLIVzUSn.pgp
Description: PGP signature