[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[vague discussion] woody boot-floppies plans



I had a talk with Joey Hess and with Eric Andersee and Bruce Perens
during Linux World and we seem to be in agreement about what
boot-floppies should be for woody.  Obviously, what follows is highly
provisional.  Still, its important to know what's coming so you can
plan any major initiatives around them.

It's not yet time to get into a big discussion about this.  Our
priority is still to fix the bugs of the potato boot-floppies and try
to support as much hardware as we can -- and this is a helluva a lot
of work.

Feel free to respond, but lets just treat this as blue sky thoughts
which are still to be worked out and administrivia.

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.

leadership:

I plan on continue leadership of the *potato* boot-floppies.  I do not
intend to be leader for any other release of boot-floppies other than
potato and potato point updates.

Joey Hess has offered to act as woody boot-floppies leader.  I'm
inclined to accept him and pass woody over to him (we'll branch CVS
for potato when he wants to start on woody), but if anyone else wants
to be considered, please speak up.

I may continue to be involved with woody boot-floppies documentation
however.

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.

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.

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.

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.

-- 
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>


Reply to: