[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new demo system -- chrooted!



On Wed, Jan 10, 2001 at 12:07:51AM -0800, Joey Hess wrote:
> 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?

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?

> > 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.

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.

> > 	* 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?

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.

> > 	* 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?

Hrm, dpkg might want to be able to lookup the uid for the usernames of
the files it unpacks?

> > 		+ 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?

Isn't the timezone asked earlier anyway? If it is (and still is with d-i),
then we can just use that answer.

> > 		+ 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)?

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)

> > 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?

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. :)

Cheers,
aj

[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.

[1] Is console-apt the way to go, or should we stick with dselect?

-- 
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: pgpMFb1rQjrtO.pgp
Description: PGP signature


Reply to: