Re: new demo system -- chrooted!
Anthony Towns wrote:
> The debconf frontend should really be passed through to the udeb frontend;
> the keymap should already have been determined.
Right. How we do that with dpkg and random postinst scripts scribbling
all over the display, I'm not sure. perhaps you preconfigure everything
first (with their debconf protocol output/input just passing through to
the cdebconf frontend), then when you actually install the stuff you
redirect it to tty3?
> This reason makes the most sense to me. So, basically, configuration should
> go like:
>
> * ask just enough questions to build a self-sufficient system &
> install it
> * boot said system
> * ask the remainder of the questions
> * install the system
Right.
> > My other problem with this idea are that I feel it makes the
> > installation a little bit less robust (we discussed this on irc). I
> > would feel a lot better about it if it didn't have quite so many special
> > cases.
>
> Okay. Special cases:
> * perl-5.005 junk, should go away with hopefully new perl packages
Right.
> * devices stuff. difficult. would go away with devfs on b-f's :)
Maybe MAKEDEV should be required to make that stuff on installation if
it doesn't exist? Or does it need to exist earlier?
> * lilo needs a real fstab to configure properly, should go away
> when plugged into an installer
> * the essential pkgs install is:
> - unpack everything manually
> + lie to dpkg and tell it it's installed
> + forcefully add base-files, base-passwd, ldso
base-passwd?
> + forcefully add dpkg
> + forcefully add libc6 (which likes to have a timezone, or
> it'll prompt)
I wonder if there's something clean that can be done instead of
special-casing it? Make it ue debconf and have the debconf prompt be a
sufficiently low level so the user does not see it, then reconfigure the
timezone stuff after the reboot?
> + forcefully add perl-5.005 (and take care of its symlink)
> - install debconf-tiny
> - preconfigure everything
> - install everything, in the knowledge that all they're
> dependencies are already unpacked, even if dpkg doesn't
> know this
That last one is pretty nasty. Do you really have to force *everything*?
Is it worth considering faking dpkg out with a dummy status file (udpkg
could do that)?
> Some risky sorts of things:
> * some programs need procfs in the chroot, and some package mounts
> dev/pts when it's installed :-/
Bleh.
> * start-stop-daemon gets replaced by true to stop daemons from
> starting
Hrm.
> There's some other special cases in there that've been fixed since potato
> too, actually; the ldconfig.new stuff eg.
Well that's encouraging anyway. Do you have a sid version yet?
--
see shy jo
Reply to: