Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])

[bug1 <bug1@netconnect.com.au>]

"Karl M. Hegbloom" wrote:
> 
> 
>     Karl> I discovered today that the `boot-floppies' "root.bin" has the entire
>     Karl> libnewt.so on it, rather than a subset as I had assumed previously.
>     Karl> I somehow never noted that there's a libslang.pic, but not a
>     Karl> libnewt.pic.
> 
Talking about newt, did you know there exists gnewt, its a gnome wrapper
around newt, not directly usefull to us, but who knows, could come in
handy.

http://oksid.ch/gnewt/

>     Bruce> I hadn't got as far as looking at what is available yet, it's a variable
>     Bruce> anyways ;).  Has anyone created a map of the structure yet (how the
>     Bruce> installation will be modularized, etc.)?
> 
>  Yes.  Joey Hess has started a `debinst' repository on kitenet.net.
> 
>  <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 ?
 
>  The Woody `debconf' uses Perl and a really neat toolkit written by
>  Joey Hess called `libterm-stool-perl', which in turn uses
>  `libterm-slang-perl'.  Perl is way to large for the boot floppy, at
>  least for the first stage.
> 

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

This would be a pretty doddgy way to install a deb, but ok for an
emergency.

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

The temperary filesystem should eventullay have partitioning tools,
hardware detection (libdetect?), other GUI's etc.

Partitioning could be done via debconf.

I think it should be possible (but tricky) to repartition under a loopfs
(using LVM mirroring) providing that there is more than one
disk/partition on the target source.
Other option would be to install to ramdisk and resize the one partition
(if ext2 or fat) or else the only option would be to do  destructive
install 

An intermediate installer like this i think would make life really
simple for installing GNU/Hurd, or GNU/FreeBSD, or GNU/Plan9 whatever is
about at the time.

The intermediate installer would always be linux, but that doesnt matter
non linux stuff is just files, fine tuning can be done after a reboot in
the native OS.

The kernel should not be a general purpose kernel, it should
specifically be for floppies. 

All the boot floppies and boot kernel *needs* to do is be able to
contact to debian binary archive (or a subset of it), after that space
shouldnt be a problem.

So my thoughts are that we should be able to do a read-only
non-destructive installer to handle foreign (non-linux) OS's and it
should be able to fit on 1 floppy.

<snip>
>  We really need `dpkg' to have the ability to filter what it installs,
>  and to mark the installation as having been partial.  It should be

If we use an interim install partition then we can do a "trashy" install
for the interim installer as long as it doesnt effect the final install.
(maybe this is taking you out of context though)

>  possible to install everything but documentation, or conffiles only,
>  etc.  This way, you can install most things only on a NFS file
>  server, but still have configurations installed on each host, with
>  automatic updating via `dpkg' available.  You should be able to
>  change your mind, and say something like `apt-get --docs-only install
>  PKG', or something like that.  I'm not the one who can design that.
> 
>  Hmmm... `dpkg-reconfigure dpkg'?  dunno.  This is Joey and the
>  `dpkg'/`apt' developer's department.
> 
>     Karl> The main menu could be nicer also...  anyway, if you've any good
>     Karl> ideas, let me know.  I'll be on IRC all evening.
> 
>     Bruce> I don't see why any of the installation ought to be serial.
> 
>  Right.  I've grabbed Red Hat's `anaconda' package, which is their
>  installation system.  It's worth haveing a look at.  Most of it is
>  written in Python, with both a `newt' and `gtk' interface.  I've not
>  yet seen it in operation.  It looks like they have a `busybox' alike
>  thing, called `collage'.  A quick look tells me that we should stick
>  with `busybox' and that perhaps Red Hat ought to look at it also.
> 

Python has some good points, but i think we should as much as possible
to integrate our configuration into debconf and the packages that relate
to it (even make up virtual packages), it makes the configuration
process more easily reusable for debian users.

>  They have device detection codes worth haveing a look over also...
>  so does Corel Linux.
> 
Redhats hardware detection is called kudzu, i believe mandrakes
libdetect is better than kudzu (for isa cards at least).

>  Red Hat's `libfdisk' contains a partition editor with a `newt'
>  interface.  It might be possible to port it to our system and hook
>  that into our Woody `debinst' `dbootstrap'.
> 
What about parted, it doesnt have much a of a GUI, but it wouldnt be
hard to do i dont think.
I think the ability to resize existing partitions (non destructivve
install) is one most users would really like.

>  Can shell scripts be compressed and executed via "zcat SCRIPT |
>  /bin/sh"?  Would that buy us some space?  How about other
>  executables?  Can they easily be compressed somehow?  (launched
>  through a shell script that does autodecompress or something?)
> 
Cramfs is a compressed read-only filesystem in 2.4, it compresses each
block, so it doesnt get the same compression as you would on the whole
file.

I have heard of a way you can make bziped executables, only read about
it though.

Glenn