Another little update for those who are interested.
I saw that in the original installer:
- you _must_ define partitions/mountpoints in a certain order, otherwise
not everything will be mounted. (that's why the dialog interface makes
you choose the mountpoints/filesystems in a very specific order,
otherwise things break)
- the autoprepare disks and manual mountpoint code implement making
filesystems and mounting them in different ways, unnecessarily having 2
different code paths for the same thing (and both of them not being ideal)
- there is a too tight coupling between filesystems - disks and
filesystems - their place in the VFS.
What I'm doing now is totally refactoring that code to be more flexible
and powerful and I'm also adding support for LVM and dm_crypt
A few of the advantages:
- no fixed order, you can define in whatever order you like. my code
should be(come) smart and reorder by itself so that it mounts / before
/home, for example
this also means dependency resolution: if you define a FS on
/dev/mapper/foo but that doesn't exist yet, then lookup what is needed
to make that first and do it.
- no hard-coding of things like "prepend $target for each mountpoint":
you can more easily control whether you want something mounted or not
and if so, whether it's for the target system or the live environment.
- keep things that do not belong together away from each other:
specifying a disk's partition layout and making filesystems are
different things (so you can make FS's on other disks too and even on
/dev/mapper devices)
also (u)mounting does not belong in the mkfs code, setting up the
fstab for the target system should not happen in partition/mkfs code, etc.
This is happening in the 'blockdevicerefactor' branch
- http://github.com/Dieterbe/aif/tree/blockdevicerefactor (source)
- http://aur.archlinux.org/packages.php?ID=21683
Still very, very early in development though...
Dieter
