Project GSoC 2013: Installer Rework
Alex Hornung
alex at alexhornung.com
Tue Apr 16 00:18:56 PDT 2013
Hi Alfonso,
I've already replied to your other email, but since you have reposted
it onto the lists, here goes my reply as well.
On 2013-04-16 03:08, Alfonso Sabato Siciliano wrote:
> I would want to work at this project: "Installer rework"
> for the Google summer of code 2013, meta information [0].
> If time permits I might add to the project the characteristics
> of another projects: "Make DragonFly multiboot capable" (meta
> information [0]) and/or "The BSD Installer" [1].
I don't see how multiboot has anything at all to do with the installer.
> The project is aimed at upgrade and partially rewrite (to add
> features) the
> installer to be much simpler to maintain.
Well, the idea is mostly a rewrite, not really partial.
> Several functions scattered around in other base utils should be
> factored
> out into libraries that both the installer and the util it comes
> from can use,
> examples:
> -partitioning (both GPT and MBR) should be factored out into two
> libraries,
> that the fdisk and the gpt tools use, but the installer can make
> use of, too.
> -disklabel32/64 functionality
> -adduser (and other user/group management)
I don't really need a copy&paste of the project description itself.
> In addition, the project will add new features to make it easier
> installation
> process for users, example: cfdisk.
> The updated installer should then make use of all these new
> libraries and
> other ones that are already available (libcryptsetup, libluks,
> liblvm, libtcplay)
> to offer more advanced features.
> Project timeline broken down by week:
>
> Week 1:
> Study the code.
You should study the code long before GSoC actually starts.
> Week 2-5:
> Scattered functions should be factored out into libraries.
You need way more detail here - a detailed list of all the
functionality you think needs to be factored out into libraries.
> Week 6-8:
> Add new features to the installer.
As I was saying, this is not about adding new features, but pretty much
rewriting the whole thing. As it is now it is hard to maintain and
adding new functionality is painful. Three weeks for a complete rewrite
of the installer is way way way way too little.
> Week 9-12:
> Testing and I might add to the project the
> characteristics of projects: "Make DragonFly multiboot capable" [0]
> and/or "The BSD Installer" [1].
As I mentioned earlier, I don't see how multiboot has anything to do
with this, nor what exactly you mean by "adding characteristics" of the
bsd installer.
I don't think you have given this anywhere near enough thought. One
aspect is the factoring out of utilities into libraries that the
installer can use, yes. But beyond that, there's a huge amount of work
and *design* to do.
Some aspects you should be thinking about:
- we'd like to keep an ncurses interface, but it'd also be great to
have it completely scriptable for an unattended install.
- in line with wanting to keep the ncurses interface, there needs to
be some thought as to what library to use for that - but that depends
on
the language used overall (see point below). Using raw ncurses is way
too painful.
- Being able to script the dialogs in a language other than C would
be
ideal - this may mean embedding something like a Lua interpreter and
exporting functions to it, or maybe even write the whole installer in a
language like python or ruby.
- What is the best way of handling partitioning? It is arguably the
most complicated part, as there are lots of options. Just invoking
cfdisk doesn't cut it because of the way BSDs normally handle disk
partitioning using BSD labels (disklabel32/disklabel64). Not to mention
that there are more advanced features like swapcache, encryption, etc,
that I'd also like handled gracefully. The debian installer is a great
example of how this can look.
- What dialogs should the installer have? We want a short and
painless
install process, but it should be possible to set up something more
advanced as well. How does this compare to the current installer's
dialogs?
HTH,
Alex
More information about the Kernel
mailing list