[woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
>>>>> "Bruce" == Bruce Sass <bsass@freenet.edmonton.ab.ca> writes:
Bruce> Hello Karl,
Bruce> I was gonna send this to the list, then noticed the subject was
Bruce> [dbootstrap], not [woody]... maybe you will find it interesting.
I posted to the list, since that's where the other team members will
be. The more the merrier. Hope you don't mind, Bruce.
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.
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?)
Karl> Given that the full functionality of Newt is at our disposal, I think
Karl> we ought to put some work into the GUI, and utilize things like
Karl> newtGrid's and whatnot. I'm going to start learning Newt, and see
Karl> what I can come up with.
Karl> I'll try to keep in mind that there needs to be a generic interface
Karl> that can be implemented by other GUI frontends, in the way that
Karl> `boxes.c' and `bowl' do it now. I'm going to break things on purpose
Karl> though, just for the freedom of it. I'll do a newt interface, if I
Karl> can, and not worry too much about `bogl' for now.
Bruce> What does debconf support...
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.
Karl> Any ideas as to what it should look like and how it ought to look? I
Karl> took a hike up the hill today and thought about it some. For one
Karl> thing, the partition / format / fstab stuff ought not be serial; it
Karl> ought to be one or two screens of setup, then it runs all the
Karl> commands to partition, format and mount.
Bruce> I've been thinking about this off'n'on since slink's bf (or was it
Bruce> debian-admin when debconf started(?); ya, I'm a floater :).
Bruce> Mmm, I really should have a look at debconf, <shrug> later.
Bruce> One should be able to have generic frontends for text, newt, GUI, ...;
Bruce> and installers for each item needing attention. The installation
Bruce> scripts for each resource would drive the frontend (or is it the
Bruce> reverse?) in whatever manner was appropriate for the UI (linear, menu,
Bruce> etc.), maybe it can be prototyped by creating package files in the
Bruce> dpkg DB (for the sake of discussion, dev-<device>.debs).
Yes, that's essentially how it works, as I understand it. I've
honestly only given it a cursory once over, and pushed it back in my
queue of things to learn about in the future.
Related to this all are things like the Gnome library for a
"registry" like configuration database, and stuff similar to Red
Hat's `kickstart'.
It would be good to have a shared library for reading configuration
data with, and to have the multi-host database thing for any
arbitrary program (bind, smtp-server, init.d, backup set definitions,
etc.). There ought to be a site-wide one for more global data, and a
per-host one for more local data, with the site-wide one supporting
centralized configureation data for satellite systems if
desired. (clusters, thin clients, student workstations) I could be
`dhcp' / `ldap' like, I guess. There's a book out, iirc from
O'Reilly, on "directory servers" or somesuch. It would be worth a
read during thourough research prior to attempting a solution.
(let's kill `linuxconf' once and for all)
Bruce> e.g., create a package for each harddrive, supply {post,pre}.{inst,rm}
Bruce> scripts that install and configure a harddrive; an initial installation
Bruce> could do "dpkg --install dev-hda.deb", a running system would use "dpkg
Bruce> --configure dev-hda" whenever bits need to be fiddled with.
Hmmm. Sort of like a shell script you'd hook into the rc.S script
that would use `sfdisk' and `mkfs', etc. to auto-install when you
know the drive is factory fresh or burnable... but done up right
with a tool made for the purpose. I imagine that the folks at VA
Linux have already put quite a lot of thought into this problem.
(perhaps when I get some more college out of the way they'd like to
teach me to help them with it)
Bruce> Dbootstrap would need to: set up a minimal dpkg system (just the guts,
Bruce> flag the packages involved as `reinstall required'), "scan"[1] the setup
Bruce> to create an initial set of dev-* and config-* packages, turn the user
Bruce> loose with a list of all the `packages' and let the dependencies work
Bruce> themselves out. Ok, that last bit needs some work. ;)
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
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.
They have device detection codes worth haveing a look over also...
so does Corel Linux.
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'.
Bruce> [1] scan == hardware probes, auto-configure stuff, defaults, ...
Some questions, off the cuff, without even trying first to find the
answer myself, just because I thought of them only right here and
now...
How big is the `slang' language? Will it fit on the boot disk, and
can we use it for anything a shell script wouldn't be suited for,
like to script our installer? Can code for it be byte-compiled
and/or compressed?
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?)
Today I need to spend time setting up my backup system here. It's
been keeping full backups using `tob' every day, and I want to make
it use diffentials, etc. I also want to do a little work on my CVS
checkout sparse backup script too... it will archive only files
changed since last `cvs update'.
Reply to: