On Sat, Jan 09, 1999 at 01:40:56PM +0800, Mikolaj J. Habryn wrote:
> Which layer are people working on standardizing at the moment? I
I don't know.
> don't think there's too much doubt that pre/postinst scripts will need
> to change. The single greatest problem is that everybody is including
> their own routines to obtain information.
Good point. New goal: Standardization of configuration input.
> Are there any suggestions being floated that don't require that
> every package that queries the user explicitly be changed in some way?
I do not know how we could accomplish this. I have an idea how to handle
non-interactive installs in transition:
I do not know much about shell programming, but could we modify dpkg to stop a
program that waits for input? The shell can do that. Then it should obtain a
screendump and save it somewhere. After all non-interactive scripts are
completed it could restore the screen for each stopped program and continue
the script.
Just another thought I just got - policy says postinst should be omnipotent.
It should handle being killed wherever it happens. dpkg could just kill every
process waiting for input. But - does dpkg notice that at all? AFAIR scripts
should use /dev/tty (questionable IMHO) which can not be monitored by the
shell.
> Standardize an interface (dpkg-option, as someone suggested, or
> whatever - *anything* will do, as long as it is extensible), and let
*g* I suggested that.
> the packages get converted. As maintainers look at the new system, let
> them raise issues and then resolve them.
Great idea - incremental move to the new scheme.
> A simple first cut would be to write a dpkg-option that does exactly
> what the different maintainer scripts are doing now (ie, read from
> stdin). Then write a few different ones to look prettier (eg, a
> graphical gtk based one, a pretty ncurses version, etc), stick them in
> different directories, and have apt set the path appropriately.
I like that idea. Could we scan all the postinst-scripts for interactive input
to see what is needed?
> There's a thousand different paths that implementation can (and
> probably will) take; I suggest that perhaps we should encourage
> package maintainers to raise the real issues that will need to be
> addressed, and the easiest way to do that is to float the new
> interface, provide a thoroughly basic implementation and see what they
> say.
Okay - let's implement some simple tools and see what the community thinks
about it :)
> m.
cu
Torsten
Attachment:
pgpS36_wwTKYo.pgp
Description: PGP signature