Do we really need our own installer?

[Hartmut Goebel]

Hello,

I would like to bring this topic to discussion: Do we really need our
own installer? No offense meant, I strongly appreciate John's and
Danny's work on the installer. I just have some doubts if this is the
way to follow further.

Foreword: One of the really cool things about guix is that everything is
at hand: Building packages, VM, disk-images, even the iso-images for
installation. Where for other distributions you need additional tooling,
for guix you need just to type a command. That's really great.

But do we really need our own installer? Why can't we "just" adopt an
existing one to our needs? Does the installer need to be part of the
"guix system" command?

As you may have read the last days, I tried installing GuixSd from the
installation medium the first time – and had quite some trouble let
alone the partitioning. Because of this I demanded the graphical installer.

Today I tried the graphical installer and got a bit shocked. Not about
the installer being in a quite early stage (that's what I'd expected),
but about the enormous pile of stuff still need to be implemented: LVM,
encrypted disks, a partitioning-tool friendly to beginners, filtering
unusual keyboards, pre-setting the keyboard based on language selection,
setting up the graphic display, and so on. And after this is done, we
still have a old-fashioned ncurses installer, not a GUI. This is not
attracting people.

A possible solution would be to adopt an existing installer to our
needs. This *may* not allow to fully leverage the features of guix
within the installer (but IFAIR guile can be accesses from C), but my
assumption is we only need parts of it.

On the pro-side we may get a much more capable installer much quicker.

On the down-side, we can no longer integrate the installer into "guix
system". Which brings me to the next question: Should there be something
like "guix system installer"?

IMHO there should not be something like "guix system installer" for
these reasons:

- To complete the installer (to be par with other tools), a lot of code
needs to be added. But this stuff is only used for installing a system,
which means a very short time in the life-time of a system. It is not
used for disk-images, virtual machines and containers.

- It adds ncurses to the requirements and thus increases the minimal
system footprint of guix.

- If we (later) want to implement a X11-based installer, we can not
include this into "guix system installer", so we need to implement
something different – which will either lead inconsistency and trouble.

What do you think?


FYI: I *briefly* looked at Anaconda [1] (used by RH/Fedora, implemented
in Python3, C, and GTK+, which also as a text-based interface, and
Clamares [2] ("a distribution-independent system installer", implemented
in C++, Python and Qt). There also are * Ubiquity [3] (used by Ubuntu,
written in Python and GTK+) and the Debian installer [4] (written in C
and *may* still have a ncurses interface).

Calamares seems to be most actively developed, supports branding and
seems to have a nice design, splitting between "Vies" and "Jobs".
Anaconda as a text-ui, which is a good thing, but documentation is
terse. From the Debian installer I would retire since C IMHO is too low
level – and I mind to remember Debian is lagging a lot.

[1]https://en.wikipedia.org/wiki/Anaconda_installer
[2] https://calamares.io/
[3] https://en.wikipedia.org/wiki/Ubiquity_(software)
[4] https://en.wikipedia.org/wiki/Debian-Installer

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| www.crazy-compilers.com | compilers which you thought are impossible |

0xBF773B65.asc
Description: application/pgp-keys