On Wed, Jan 10, 2001 at 05:21:38PM -0800, Joey Hess wrote:
> Well I was thinknig if all the interaction was during preconfiguration,
> we wouldn't have to worry about that since we could reasonably expect
> there was no extraneous non-debconf-protocol output.
> But on reflection, these packages are going to be using debconf only for
> critical level stuff, which often means failure messages, recovery from
> bad situations etc. Things that you run into in a postinst.
Right. We could just declare "any failures are fatal, and will be reported
with a generic `Something bad happened trying to install the base system
:(' message", and maybe even get away with it, but... :-/
> So I don't think that we even need to preconfigure them. And we do need
> to redir the output somehow.
Well, we can't redirect the output unless we redirect their input too, and
we can't redirect their input while debconf needs it. :-/
> Can you refresh my memory about how the unix socket forwarding stuff
> would look?
Well, I thought I could, but I can't.
You'd need to have a Unix socket in /target/var/run/debconf.$$ or so
that the cdebconf frontend is listening on. This'd then be passed via
the environment to create_chroot.sh; which'd then remove the /target
prefix and pass it on to debconf-tiny from base.
But anna can't rely on /target/var/run being partitioned or formatted,
let alone setup with the appropriate socket in there. And cross-filesystem
hardlinks don't work, and you can't symlink out of a chroot.
Hmm. I guess another possibility would be create_chroot.sh setting up a
faux-passthrough frontend, so that it all ends up looking like:
cdebconf-backend /var/run/debconf.1 -- cdebconf-frontend
\ / |
cdebconf |
\ |
create_chroot.sh |
|
faux-passthrough-gui
|
/target/var/run/debconf.$$
|
chroot dpkg-preconfigure
|
debconf ConfigDb backend
That is:
* cdebconf only ever has a passthrough frontend
* create_chroot.sh can duplicate the passthrough frontend into
/target
* possibly, then, the cdebconf-frontend may have to cope with
multiple simultaneous connections across the socket? dunno
about this one
All together now: yuck.
I've taken out base-config and switched to the Noninteractive frontend
for the moment instead...
> > Isn't the timezone asked earlier anyway? If it is (and still is with d-i),
> > then we can just use that answer.
> No, d-i is not going to configure timezone. Some real package in debian
> will have to do it after reboot.
Won't that break the timestamps on some of the files the installer creates
(/etc/fstab, eg) though? If, say, my hardware clock's set to localtime,
and my TZ is +1000?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgp86YvFWWIBy.pgp
Description: PGP signature