On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck wrote:

quickinst: http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb... Is there anyone who actually uses this? If so, can you tell me why?

It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.

What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?

Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.

I'm wondering if shouldn't just drop it.

Note that with AIF it's quite easy to implement a "partial procedure", which is a procedure to do one or a few specific things. (right now there are partial procedures which let you do keymap/font selection, disk/partition/filesystem config, and network setup).  I could add one  to let the user just do package selection & installation, for example.

Dieter

On Sun, Mar 8, 2009 at 6:38 PM, Dan McGee wrote:

On Sun, Mar 8, 2009 at 10:05 AM, Dieter Plaetinck wrote:

...

quickinst:

http://projects.archlinux.org/?p=installer.git;a=blob;f=quickinst;h=23e41ccb...

...

Is there anyone who actually uses this? If so, can you tell me why?

It's stated quickinst is meant for people who want to mkfs/mount their filesystems themselves, okay I understand that. But, as a "consequence" you can only install the base packages, your keyboard/time/.. settings don't go into /mnt/etc/rc.conf automatically, you need to install the bootloader manually (which means having to mount some things yourself, chroot etc.

What is the advantage of this over just using the normal installer and skipping the steps you don't want to do?

Because the normal installer is a manual process. You can't easily do a remote install on 30 machines with a dialog-based installer, while with quickinst that becomes quite easy.

...

I'm wondering if shouldn't just drop it.

Note that with AIF it's quite easy to implement a "partial procedure", which is a procedure to do one or a few specific things. (right now there are partial procedures which let you do keymap/font selection, disk/partition/filesystem config, and network setup). I could add one to let the user just do package selection & installation, for example.

I use by same reason.

...

Dieter

-- Robson Roberto Souza Peixoto Robinho robsonpeixoto@gmail.com Telefone: (19) 8821-0396 Computer Science Master's degree student, University of Campinas Archlinux-br Developer Team - http://archlinux-br.org Linux Counter #395633

On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck wrote:

* aif -p automatic -c /path/to/configfile: the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config

This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine. I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though

On Mon, Mar 9, 2009 at 5:29 PM, Thomas Bächler wrote:

Aaron Griffin schrieb:

...

On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck wrote:

...

* aif -p automatic -c /path/to/configfile: the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config

This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.

I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though

I agree.

Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.

My only thought is whether this is even necessary- I'm guessing most people used quickinst as just a part of a full automated install (e.g. shell script that first does partitioning, mounting, etc). I wouldn't mind a tool that takes care of this for me, but if it isn't useful for a wide variety of cases, it won't be used. In addition, any config file format we write is surely not as flexible as a shell script would be. -Dan

On Tue, 10 Mar 2009 09:32:54 +0100 Dieter Plaetinck wrote:

On Mon, 9 Mar 2009 20:01:35 -0500 Dan McGee wrote:

...

On Mon, Mar 9, 2009 at 5:29 PM, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...

On Mon, Mar 9, 2009 at 2:55 PM, Dieter Plaetinck wrote:

...

* aif -p automatic -c /path/to/configfile: the recommended way: you have the ability to specify partitioning/filesystems/package lists/hostname etc in a config file format which i'll try to keep as simple as possible. that, and the ability to define custom hooks and whatnot to implement custom logic in your config

This seems the most ideal here. If we're assuming you're mass-installing or something of the sort, the installer needs to know all this information for each machine.

I think we should even skip the initial "quickinst" copy and just go this route - though providing a sample config file would be necessary though

I agree.

Someone could easily create a custom installation medium with a custom aif automatic configuration and use that for mass installation.

My only thought is whether this is even necessary- I'm guessing most people used quickinst as just a part of a full automated install (e.g. shell script that first does partitioning, mounting, etc).

I wouldn't mind a tool that takes care of this for me, but if it isn't useful for a wide variety of cases, it won't be used. In addition, any config file format we write is surely not as flexible as a shell script would be.

-Dan

Aha ! This is actually the very reason I started this all. I want for myself to have a script that does all this cool stuff. (the port of /arch/setup is just a little side project as far as I'm concerned ;-)

And you're right that a file format adds another layer of complexity, but you get some free stuff in return such as the rolling back in case of failure, no need to program sfdisk input (which is quite ugly). If no one will use this particular part of aif.. well that's fine by me. we'll see :)

Dieter

Hey dudes. I got rid of the quickinst stuff and implemented the automatic procedure. In my tests, it produces working systems. One thing to note: when the process is done, and you type reboot, you'll get squashfs and i/o errors on the live /. didn't figure that one out yet. You can install it by installing aif-experimental-git package from AUR. Invocation: aif -p automatic -d -c /usr/share/aif/examples/generic-install-on-sda To get an immediate idea of the code and sample config (which are actually very simple), see: http://projects.archlinux.org/?p=aif.git;a=blob;f=src/core/procedures/automa... http://projects.archlinux.org/?p=aif.git;a=blob;f=examples/generic-install-o... Have fun! Dieter