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

Re: redesigning the debian installer

Joey Hess <joeyh@debian.org> writes:

> I never said this was a complete design yet. You're right, these are
> all gaping holes:

Yeah -- I wasn't trying to deprecate your work but cast my net a
little wider, since there are a lot of blue sky / wishlist stuff
floating around.  I think the code that works best is the code that
keeps it simple.

> - A module's maintainer decides it needs one of these things (a configured 
>   network, say).
> - They make the module depend on an appropriate virtual package
>   (configured-network).
> - Before the module is used, the system makes sure its dependencies are
>   met, and that the modules that satisfy those dependencies are
>   configured (so the network is configured, but first hardware support 
>   for it is set up).
>   (I need to change how the main menu works a little bit, come to think
>   of it. More on this soon.)

So this is all micro-dpkg stuff, using Depends/Provides ?

Clearly you're going to need to arbitrate a set of virtual package
names for the fundmentals, such as "configured-network". 

How does this work with attempting to configure your targetted media,
i.e., IDE, SCSI, NFSRoot, PCMCIA IDE device -- "configured-boot-media"
and "configured-target-media" virtual pkgs ?  And
"configured-installation-media" is where we're installing from,
provided by "install-from-cdrom", "install-from-http", etc.?

So the installer basically proceeds through installation steps, which
is a process of installing more and more packages, perhaps leading to
an overarching completed installation of "installed-debian" ??  Thus
it knows that it's time to install "configured-target-media" so it
tries to fullfill that dependancy, presenting the user with all the
possible micro-pkgs which fulfill that?

This is starting to make my head spin.  Are you sure we're not
overdesigning/overabstracting a bit?

> My point is that these various classes of modules don't need to be
> specified in much detail. I don't care how a network configuration
> module works, or what programs it installs where, as long as once it 
> is set up, there is a configured network.


> Of course, that's just in general -- we do need to think about each of 
> these classes of modules and find the little details that need to be
> specified.

Well, I wouldn't underestimate it.  I mean, "configured-network" does
would have to be a standardized virt pkg name, it would have to have a
documented/specified list of things it's expected to do, etc.

Would "configured-network" only be required for any pkg which wants to
install over the network (such as installing from http, or in the
later stages, running apt with http/ftp sources) ?

> I wish we could share more, it's really silly we all go off and write
> our own installers. Um. Er.

Well, as much work as it is, it would be more risky and harder to try
to mediate one installer used by all distros.

> Right that's doable easily (trivial to map debconf db to 822-format) and
> will work fine. Or there is this mythical debconf remote database stuff
> that maybe one day someone will actually write.

Please try to keep it simple. I don't want to have to maintain a woody
boot-floppies. :)

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

Reply to: