Re: Comments, another installer project
On Fri, Sep 22, 2000 at 05:55:26PM -0700, Joey Hess 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. :-)
Not that many apart from wasting to much time on the design of the installer.
I should just have started writing the modules and build the superstructure
above it.
> > 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.
Let's see if I got this correctly. First the ramdisk will be unpacked
from initrd and then udpkg will install packages from this ramdisk
into the same? I would dislike this behaviour since we would waste a lot
of ram for having the same data twice (and Debian is often used on
small systems...).
But perhaps I got that wrong and we built the initrd for the installer by
installing packages into a loopback-mounted filesystem on the build
system?
> > 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.
Looks like it.
> > 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.
Using debconf will make the Debian installation more friendly than it is
currently. But it will hinder us from making it more friendly than other
installers are at least if we don't extend debconf to do more than it
can currently. At least that is my feeling currently. I am not a debconf
expert though and the new debconf from woody (especially with the slang
interface) looks very promising. Seems like I have to read the design
document of debconf again...
> > 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.
The problem with debconf is that it will never (and should never) have the
possibilities of a widget set controlled from C source code. That way you
can't write a nice partitioning tool (think diskdrake) with debconf interface.
But this discussion leads nowhere since I feel I am unable to express my
ideas. Let's stick with debconf for now and see if it suits our needs.
> 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.
Why are we rewriting the beast then? The current installer does that
already. I had the impression that the goal of this project is to make
the Debian installer be able to compete with other distributions again.
> > 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 just think we don't need dependencies etc. for a first prototype of the
installer. Let's make it work for the simple cases first and then add the
code for ordering etc.
Greetings
Torsten
Reply to: