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
frontends.
> 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: