Re: new demo system -- chrooted!
Anthony Towns wrote:
> > 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?
>
> Sure. I'd do this now (open up a dummy xterm or something, say), except
> that I don't have any way of separating debconf and stdio. Should we
> just add support for the unix socket forwarding stuff to cdebconf and
> debconf-tiny [0], do you think?
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.
So I don't think that we even need to preconfigure them. And we do need
to redir the output somehow.
Can you refresh my memory about how the unix socket forwarding stuff
would look?
> And `ask the remainder of the questions' would be something like:
>
> * standard / custom install?
> (a) tasksel
> (b) console-apt [1]
> * apt
> - download everything (wait)
> - dpkg-preconfigure everything
>
> Well, in theory, anyway.
See my "breaking up base-config" post, that's about this.
> MAKEDEV is *very* slow. *VERY* slow. If you rm the dev.tgz, and run
> create_chroot.sh without chrooting into a d-i system, you should be able
> to see just how slow. Only thing I can think of that'd be reasonable
> would be makedev-udeb packages which know how to make exactly the devices
> needed for whichever arch they're built on.
Well there's always devfs <flees in terror from the anti-devfs hordes>.
Glenn, how fast/slow is your makedev program?
> Hrm, dpkg might want to be able to lookup the uid for the usernames of
> the files it unpacks?
Bah, I'm used to more primitive/robust dpkg's ;-)
> 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.
> Hmm? I don't see the point: adding the --force just disables the Depends:
> checks, because I know I've already installed everything that every
> required package depends on. Adding status entries would just work around
> the dependency checks too. And I mean, these are all essential packages
> (or things essential packages depend on), so most of the dependencies
> don't need to be stated anyway.
>
> I install the important (not required) packages without doing any forcing
> at all, otoh. (Hence the "base packages can't pre-depend on non-required
> packages" requirement)
Ah, ok.
> I did at one point. It basically just needs adjusting for perl-5.6 and
> debconf instead of debconf-tiny. woody's much easier to proxy for too. :)
>
> [0] Or something to that effect. Since the real debconf is likely to have
> to wait until the perl mess is resolved before being reliable, I might
> for debconf-tiny until then even. Or not. We'll see.
I expect bod will be uploading a fix for that issue soon.
--
see shy jo
Reply to: