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

Re: Comments, another installer project

Torsten Landschoff wrote:
> Of course I don't expect it to be ready in time (since I have to complete
> my work in this month) but I think I can make some mistakes so they are
> avoided when implementing the new Debian installer. 

Since it's nearing the end of the month, I'm looking forward to word of
the mistakes you made. :-)

> What I do not like in your proposal is the idea to use packages for the
> different steps of the installation and for ordering the steps. Perhaps
> it's just my misunderstanding - I can't really make sense of the use of
> udpkg. 
> If it was only used to overcome base.tgz (which I don't really like) I would
> agree that it is a good think. Make the installer install all packages 
> which have Essential: yes or something. Implementing that looks kind of 
> complicated for me since the installer needs to seek the packages to install
> then. For simplicity I would like to stay with the current scheme of base.tgz.
> Now the install steps are Debian packages which are installed using udpkg 
> into the ramdisk (or where? We can't install the partitioning step into
> the harddisk for obvious reasons). Or did I get that wrong and we are 
> using udpkg to install them into the install image? That would be something
> I can agree with and which just occurred to me when I was writing this. 

Dpkg will be used to install modules onto the ramdisk, thus building up
the actual installer.

So what are your problems with this -- you didn't actually say.

> I do not feel quite well with debconf as installation frontend. First of 
> all it is currently one part together with the database. I did not see
> the problem when it was new but after reading a few scripts which use 
> it (in base-config for example) it looks quite crazy because it is 
> sometimes only used as dialog-replacement. I think it should be separated
> from the DB. 

Some people are working on this, if I understand you correctly.

> If we do that the solution to use debconf is technically sound and might
> save a lot of effort. Still people will complain that the Debian 
> installation is unfriendly compared to others. And I have to agree. 

I don't follow how using debconf will make the install more unfriendly.

> So I would like to have a database in the installer (which can be the same
> as used for debconf) and the possibility to use the debconf frontend or
> any other frontend. But I don't want to go deeper here since that can be
> change that later just as well.

"debconf frontend or any other frontend" ??? Debconf supports multiple

> I do not have much knowledge in this area and for my own project it is not
> really needed since we know exactly what hardware will be in there. But 
> I would like to say that I would like the installer to detect ALL hardware
> at installation time if possible. Installation with sound support right
> from the start would be something one could show off. That would be 
> possible when installing from CD. I do not care for sound when installing
> from a single floppy of course.

I see no benefit in detecting sound in the installation system when we
can instead make a regular debian package that sets it up on a regular,
already installed, debian system.

It's not worth extra pain and work to be able to "show off" that we have
detected a sound card in the installer. The installer is not something
to show off, it's something to install debian.

> The current proposal for ordering the installation steps is not fully to
> my liking. First, I don't think we need that now. Others do not have such
> a modular installer so let's just support a fixed step-by-step install 
> in the prototype.

Let's not innovate, because others haven't already?

We already have a fixed step by step non-modular install, and it is very
hard to maintain.

> I think the optimal thing would be a assistent like installer which just
> guides the user through the process step by step. In case something goes
> wrong it should tell the user about the problem and jump back. Special
> tasks should be selectable by a button "Special" or something. 

Such a user interface model is what I referred to when I talked about a
"linear mode" install. See my previous posts about it.

see shy jo

Reply to: