Re: new demo system -- chrooted!
Anthony Towns wrote:
> ./create_chroot.sh
> (wait while your base system is built)
> chroot chroot /bin/bash
> (play with your newly created, chrooted, Debian system, with apt, bash
> and all your favourite tools available)
This is way cool. Comments:
> * you end up having downloaded the latest versions of a bunch of .debs
> and your /var/cache/apt/archives directory is already populated
> with 'em
That's a good thing? :-P
> * get_debs.sh doesn't seem to work properly with busybox wget, or
> busybox wget doesn't support proxies or something. It *should*
> work, but it just doesn't seem to
Could you try to use anna and/or the debian-installer retreiver system
here? We need it to support grabbing Packages and debs from whatever
medium is being used, which might be a cd or whatever.
> Note that a lot of the complexity from b-f's disappears if you're
> allowed to interact with the end user while you're dpkg -i'ing the
> base packages...
This is the part I really dislike. The user should not be bothered by a
binch of questions about what debconf frontend and what keymap and a
million other questions (that I forget) when they are doing a fresh
install. These questions make sense when a deb is being installed onto
an existing system or upgraded, but not so much on an intial install,
when you just want to get a working vanilla system up and tweak it _after_
you know that it will boot. (I hate investing a lot of time into
installing and configuring something and only then find out that lilo is
broken.)
I think the program needs to set the debconf priority to critical so only
the most important question will be displayed (and if packages abuse
that they get bugs file or we invent an even higher priority level).
Packages that don't use debconf should not be allowed to display
anything at all, and the dpkg log should be redirected to a log file
and/or some other console.
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. Could you (or I can probably do it just by reading your script)
get a list of the special cases that are in it it to handle breakage in
other packages, and file bugs on all those packages?
But it's already very cool. I'm sure we'll use it one way or another --
it could be used to generate the base.tgz too. Do you have any plans to
make a proper debian package out of it and clean it up?
--
see shy jo
Reply to: