Re: [vague discussion] woody boot-floppies plans
Adam Di Carlo wrote:
<snip>
> General:
>
> The core features we have now must be retained, such as serial console
> install, cross-platform, console capabilities. New features ought to
> be added, such as install for the blind, automated install, UI
> install, etc.
>
> The big problem of boot-floppies is coupling. Changes in packages
> such as console-data may require changes in 3 or 4 parts of the code,
> including the build shell scripts and dbootstrap. The
> "maintainability" of boot-floppies is it's biggest thorn. Any radical
> changes should take this into account and do its utmost to reduce
> unmaintainability.
>
> modularity:
>
> It would be great if the boot-floppies were constructed so it is
> easier to add onto it, add extensions, etc. Right now there is far
> too much coupling between too many parts of the system. It's too hard
> for 3rd party vendors to participate and contribute code back.
>
This is the way i see it.
The primary limitation on the quality of boot floppies is the limited
space we have to work with.
To make maximum use of space in the boot floppy, you only want things
you specifically need for your circumstance on the floppy.
The more flavours of hardware that debian supports the more complex its
instalation becomes.
There are some parts of the install that are generic, other parts are
specific to a particular instalation.
A solution to the above could be to have a singular core module (like
dbootstrap) that is used by all installs, have everything else as a
seperate module. e.g. a network install module, install from local
storage module, install from CD module, install to local HD module,
install to NFS module, install to loopback device module, serial_console
module, newt module. Also architecture specific modules, like each
architecture would have its own kernel_arch module, and possible
partitioning_arch module. <Ok im waffling on a bit, im sure you get the
point>.
If you have a loose collection of modules you could give the end user
control of the functionality they get in there boot disk. So they could
choose to use a generically generated boot disk, or choose to build
there own customised isntaller specific to there needs.
By building a customised installer it should be possible for some people
to have a single install disk.
> I also firmly believe that the non-Debian issues much be stringently
> removed from the Debian issues. The following are non-Debian issues
> that the debian-boot group currently has to deal with but shouldn't:
>
> * hardware auto-detection (this is a Linux issue rather than a Debian one)
>
> * partitioning (cfdisk/fdisk -- shouldn't disk druid or an even
> friendly and hopefully very xplatform solution be packaged?)
>
> * boot config (hopefully working with the grub folks)
>
> There are many others.... These should be efforts with upstream
> maintainers rather than being Debian-only efforts.
>
Hmm.. these are all insues that are critical to installation, if they
arent adequately covered (to our needs) by non-boot-floppies people do
we have a choice?
But i do also think that some of these issues e.g. parititioning are
developing in a fragmented manner (every distro has there own) this isnt
good for the broader linux communtity.
> dbootstrap:
>
> What I'd like to see is the following. For one, all the core package
> level configuration, and this includes MBR selection, tzconfig, net
> config, etc etc should be broken into either new little 'foo-config'
> packages which use debconf or else should be added to the postinst
> (i.e., grub postinst could have grub autoconfig or whatever).
>
> The idea is that the only requirement for what dbootstrap is doing now
> would be install media selection, and possibly downloading the modules
> it needs for whatever type of installatino is happening.
>
I think the packages are how i see the modules above.
But to clarify what your thinking let me ask you a question ive been
grapling with.
What should the goal of bootfloppies be ?
1) install a usable minimum OS, that an enduser could use (i.e. 57MB?
base). OR
2) install just enough (kernel, busybox, ash, dpkg, apt-console) so that
the user can install there packages post-install.
> GUI:
>
> Bruce Perens and others are very very interested in GUI installation.
> I think this is a great idea; what I'd like to see is that
> boot-floppies provides a better framework onto which we could more
> easily build a GUI installer. Using the dialog or whiptail widget set
> as the basis for this doesn't make sense, IMHO.
I thing whiptail, dialog type GUI is the best you can get for a console
(without X), so it would still have to be supoorted.
If we had an module/package to do an X based isntall we can do heaps of
groovy stuff. It would be pretty big though and could require extra
though in other areas. We could use space from the local hdd (loop on an
existing paritition) to support an X install, but that would require
extra consideration at the partitioning stage.
I think python could adequately meet our needs, it has support for
dynamic modules, its simpler than programming in C, more readable than
shell scripts.
We could benefit from some indepth details of the installation process
of other distro's, i have heard that redhat uses python, not too sure on
corels install method, ive heard some good things about mandrakes new
install. Ill try and pull one of them appart and give a report. Maybe it
could be a weekly thing.
Thanks
Glenn McGrath
Reply to: