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

[Gerhard Brauer]

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.

> > 
> > 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?


> > 
> > First: The above mentioned aif scripts are not the answer - syntax,
> > presentation and documentation are more the "proof-concept" to look for
> > answers.
> 
> what do you mean exactly?  the syntax is too hard for the config files?
> I do think the disk section of the configs can be made more simple. (see also http://bugs.archlinux.org/task/15640?project=6), but i like the other stuff.

I mentioned this only as an example. Remember what i want: The user must
edit his partitioning and blockdevice setup in control file. So the
syntax must be a) documented and b) a little bit more intuitiv. Ex: User
has a windows partition (sda1). It must be clear what he has to enter in
BLOCKDATA setup to a) prevent this partition (or we go everytime the
hard way and erase each fat/ntfs partition <g>) and b) to create
additional primary/logical partitions..

But this discussion is for me at this point a bit to detailed. I like
more discussions on my main cause...

> > 
> > Pros & Contras
> > ==================
> > 
> > 1. Making the settings for installation in a control file gives not that
> > pressure to the user what a User-Interface(UI) based installer has.
> > Working with this file ("editing") does not any bad things. Look for ex.
> > on the grub part currently in interactive AIF: The user is confronted in
> > this step with questions in a very isolated manner. This step is very
> > interdependent from the previous blockdevice setup - but these
> > information's were entered before 10 minutes and out-of-users-sight in
> > this step. In a editor all information is easy browseable and
> > corrections could make at any point.
> > IMHO a pro.
> If the information we need was entered earlier, we can probably reuse it by storing it in a variable.
> (like we do now for some things like proxy server, keymap etc)

Yes, i think we could refactor such things a better way (think about how
often we look if we at the current step have a separate /boot partition.
But: Why put time in this when the control file paradigm give the
installer all informations in "one piece"?


> > 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 


> > 
> > If we use the control file based install we get rid off from such
> > discussions of the "neatest" installer... And IMHO the step away from
> > "how the others do it" could make us very modern...
> > IMHO a pro.
> I don't think there is anything wrong with ncurses / std{in,out,err} per se.
> But in general, yes: the simpler the better (as long as it's still easy)

And the simples way (from AIF sight!) is surely the
control-file/automatic approach. And my point: I think it's also the
simplest way for the user (if he/she has a base linux knowledge).

I think on this from my steps to Archlinux: In 2007 i came from Debian
(i have loved it and i still do), i only tried other distros cause
myself was not able to get it worked on my Laptop. Installation was no
problem with 2007 installer for me.
If i now think that i have had at this time a Readme that advises me to
edit a control file to start the installation - then i sure would have
wonder a little bit, but when the content of this file were intuitive
then i would have no problem with this...


> 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...)


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


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


> Dieter

Gerhard
(who has expected many more replies on my mail, but maybe you all say:
Yes, that must be the sun which makes him silly... <g>)