Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
I had meant to not have this discussion until potato was released,
so as to not distract from the more important work on getting
potato boot-floppies polished, but we're probably close enough.
bug1 wrote:
> > <URL:http://kitenet.net/cgi-bin/cvsweb/joey-cvs/public/packages/debinst>
> >
> > (Joey? Please let me know if that's not meant for public
> > consumption. If that's the case, can you please move it to c.d.o?)
> >
> I checked it out, hasnt been updated for a few months, is it still "the"
> plan ?
It's just a rough draft, don't take it too seriously (ignore the code).
The ideas I stress are important are:
1. Modularity.
2. Do the absolute minimum in the installer, do as much as is possible
in the full debian install.
> I cant hold on any longer, here is what ive been thinking.
>
> All the boot floppy has to do is be able to locate the debian binaries,
> then busybox ar
> , tar and gunzip can unpack the binaries to temperary filesystem, either
> ramdisk (or ramfs) or loopfs
>
> Once the installer can access the debian binaries it can unpack dpkg-deb
> and its dependencies which are libc, libstdc++, ldso and libncurses
> (only for dselect).
>
> Once dpkg-deb is available it can easily install apt and debconf to the
> temperary filesystem.
>
> Once these (apt, debconf) are running on a temperary filesystem we are
> home free, we could just have a virtual package called install.deb
> and/or install-stage<N>-<arch>.deb, this virtual package could contain
> the next stage of the installer which will fetch any other packages
> required (apt --fix-missing) and fill out the temperagy filesysytem.
I think this would require a minimum of 16 mb of disk space, and
probably a bit more. Since with ramfs, disk space == memory, this
would limit installations to systems with around 20-32 mb of memory.
I don't think that's very acceptable.
I don't see how you could use loopfs without having first
identified, partitioned, formated, and mounted a disk. If you're going
to do that, then you might as well use my original proposal about
this[1], which uses modular code to get the partitioning and so on done,
downloads and extracts a base tarball, then chroots into it for the
rest.
> I think having a static install.deb is important as it allows us
> (install team) to divorce ourselves from the current status of base, we
> dont have to do anything if base packages change, the isntaller will
> automatically fetch the latest versions of each package.
Yes, I agree it would be nice if we could not use base.tgz for the
install, and build up a filesystem from actual .deb's. I actually
mentioned that in my original proposal[1].
> The temperary filesystem should eventullay have partitioning tools,
> hardware detection (libdetect?), other GUI's etc.
>
> Partitioning could be done via debconf.
Debconf's frontend is too inflexible for a partitioner, you need a real UI
there.
The question of how the UI should work is the weak point of my current
proposal. I've been wrestling with really two orthagonal issues:
1. How should the UI work? I rather like most of our current UI, but
is it really the best way to handle things or have I just become
accustomed to it? My proposal is to have a modular installation
system, which means that modules need to be able to hook into the
UI. Note that this is not about UI toolkits, but about UI design.
2. How should information from the UI be stored, for use later on (and,
presumably, for use in a kick-start like thing to anable mass installs)?
Here debconf seems like a fair fit, although it would have to be
redone in C.
--
see shy jo
[1] http://kitenet.net/cgi-bin/cvsweb/joey-cvs/public/packages/debinst/doc/design.txt?rev=1.1&content-type=text/x-cvsweb-markup
Reply to: