[arch-releng] Draft - Beyond AIF, long live AIF...

[Dieter Plaetinck]

On Wed, 19 Aug 2009 18:52:43 +0200
Gerhard Brauer <gerbra at archlinux.de> wrote:

> Am Montag, den 17.08.2009, 20:49 +0200 schrieb Dieter Plaetinck:
> > On Mon, 17 Aug 2009 19:19:22 +0200
> > Gerhard Brauer <gerbra at archlinux.de> wrote:
> > 
> > > Installer paradigms
> > > ====================
> > > Today installers (either if graphically or text based) are mostly
> > > interactive tools. They ask the user for information and the user is
> > > giving data to the installer. Also the user must make decisions in some
> > > steps, say Yes or No. Also in current AIF in interactive mode.
> > > 
> > > Usual a installation is a top-down and sequent work-flow. But this don't
> > > prevent that user do "silly" things. So installers (also AIF) must do
> > > many things "behind the view" to intercept mistakes. 
> > 
> > I don't think aif does much checking for mistakes from the user.
> > The only things I can think of: notices for missing swap/root/home etc,
> > and checking if steps are completed succesfully. Little code overhead here IIRC.
> 
> It's not only the "mistake prevention" (see how grub part in
> lib-ui-interactive and lib-blockdevice is grown only from grub/sw-RAID
> refactoring. OK, this is not the very best code, but an example).
> Compare the UI related code against what you/we have/need for the
> automatic part.

the grub stuff in -p automatic is much less advanced. and it uses grub-install, whereas the interactive one calls 
`$var_TARGET_DIR/sbin/grub` and passes lowlevel statements to it.
We can probably refactor the interactive grub stuff to be more concise (using grub-install among others)

Also, look at like this: often you need all the "fancy" logic anyway for the automatic procedure (detecting boot device, figuring out the order in which to create filesystems, etc)
I think the interactive procedure really doesn't add that much code.

> > > 
> > > Main problem IMHO is: a today installer doesn't know at the beginning
> > > with what information it will conclude at the end. So each needed
> > > information for a step has to be asked/determined before this step.
> > 
> > maybe we should estimate how much extra code is needed for these things.  I would guess a few hundred lines maximum.
> 
> We could do this also in interactive, sure: previously get all
> informations before doing any install related commnds. But why? Why not
> edit this in control file instead ask everything via dialog?

I've given some arguments in the mail you're quoting already (the most important one being that you can do it fast and without thinking/researching too much).



> > > If one has the idea to write a web-based interface to generate such
> > > installation control file - why not?
> > 
> > i hate webinterfaces.  I get your point, but I would do it with shellscripts.
> 
> I don't meant user procedures, i meant the control files (what we feed
> to AIF with 

You were talking about webinterfaces to generate the config file for the automatic procedure.
I'm saying I prefer shellscripts over webinterfaces (to generate those "control files")


> > I've also been thinking the installer currently does too much hand holding.
> > Especially if you compare to an arch system after it is installed: it lets the user manually invoke pacman and let him edit rc.conf himself etc.
> > There are no fancy wrappers then, so we probably don't need them during the installation either.
> > 
> > I do think it's very beneficial to have a method to install arch:
> > - that requires you to do no single keystroke more then needed to give you the system you want.
> > - that does not take any second longer then needed.
> > - that assures you you didn't forget anything
> > This is where -p interactive is very good at. No matter my love for automated installs, it's nice that you can almost brainlessly do the interactive one and end up very quickly with a customized install.
> 
> That's right, and something you/we could be proud of.
> And now I want to kick this completely ;-) (Am i evil? Yes, i am...)

Why kick it, as it has a valid use case?
Maybe we could make (on the longer term) the automatic stuff more the "recommended way" and have the interactive procedure as a secondary method, but i definitely wouldn't drop it.
> 
> 
> > I like the idea of simple scripts that generate config files for -p
> >  automatic. based on a few questions, output of fdisk -l etc. (actually
> >  I think this is how Gentoo is doing it now, or at least how one of the
> >  Gentoo relengs planned to do it.  I've been chatting with one when
> >  working on early aif) But if you want to generate all fine nuances
> >  into the config file, the script will become as complex as -p
> >  interactive.
> 
> Yes, it will be complex. But then comes IMHO my point 1) by Pro&Contra
> into the game.
> But only complex scenarios need complex control files.
> Think about when we may want to add sw RAID into installer: the needed
> code for UI will be X-size bigger than only for automatic AIF....

Your point 1 is not an argument to throw interactive away.
especially since your example (the grub stuff) is not a fair comparison (see above)

> > note that the "store disk layouts in a nice format, and programatically
> >  parse those formats and act correctly on them (invoke mkfs, mount
> >  etc)" we currently do requires quite some code (rough estimate: about
> >  1000 sloc). I've been thinking if it wouldn't be better to let the
> >  user write scripts in which he does 'mkfs.. mount..' himself.  it
> >  would definitely be easier to code, but the current approach offers
> >  some features like rollbacks etc which you otherwise would have to do
> >  manually (or script it also), which would make the users
> >  scripts/configs uglier.
> 
> The approach that user (who "only" will install a system) have to write
> scripts is not a way IMHO. That's something for the experienced user who
> will for. have own procedures for a special case.
> 
> The rollback is IMHO no problem (also in automatic way). I mentioned
> already that we definitely a "Last chance to press Control-C!" before we
> do anything with (c)fdisk and/or mkfs.*. At this point we could easily
> implement also the rollback... Also in grub setup step...

the rollback destroys any newly created dm volumes (lvm and such) and umounts new filesystems,
it's only goal is making it possible to define (and create) new setups without breaking over things that are in use or still mounted. (but this is off topic)

Dieter