I've been working on an AIF module for a while and yesterday posted a brief note on the forum and exchanged a mail or two with Dieter about it. I'd welcome feedback on it from the releng team and would like to cover an issue I'm having during install from the ISO that appears to be either filesystem or makepkg related. Archiso team feedback would be great, in particular since this only occurs when run from ISO (which doesn't mean it's related to archiso, but archiso team members might at least be able to tell me why it isn't if that's the case). I'll pop into #archlinux-releng as well later (nick altercation). On github --------- https://github.com/altercation/figtree Features -------- * Keep your system config in version control. Access locally or remotely (github currently supported, framework in place for other dvcs/hosts) * Separate hardware specific packages, configuration files, and values from other profile scope. (implemented already) * Add overlay files and expanded configuration values to AIF installation. (implemented already). The systems/lenovo/x220/profile in github is an example of a hardware specific profile that makes good use of overlays. * Access the profile at install time from the Arch ISO via AIF (figtree automatic procedure; already implemented) * Easily update the profile from a live system; easily update a live system from the profile. (partial procedures; work in progress) The readme on the github page should be fairly comprehensive. I haven't implemented user config/home directory functions but it's one of the next big features to work on (I've already implemented it in an older script; much of this is rewriting / refactoring of those older, non AIF functions). Feedback on architecture ------------------------ I hope this isn't off topic for releng and welcome feedback about the general approach I've taken. I hope that figtree might become useful for others, particular in regards to sharing hardware specific install starter configs. I was hoping that system profiles might serve as an adjunct to the arch wiki in terms of sharing config file samples, for instance. The implementation as it stands, while not trivial, is up for revision. For instance, the functions I am using in the profiles (packages/daemons/config) are, I think, easy to understand and not needlessly abstracted or complex. It's possible to do away with them entirely and just have the user add values to a variable instead (CONFIG_CHANGES+=("more changes")) but I felt that this was more error prone and potentially harder to scan. Ultimately, I wanted to keep it simple and stick to DRY / DROP (don't repeat other people) principles. Dieter's AIF architecture really works for this and I hope that figtree might evolve into something useful that allows dvcs based sharing. I'd like to actively solicit feedback on this here. Install Issue (archiso team feedback requested) ----------------------------------------------- (maybe split this mail thread if this is best handled separately) I'd very much like to support AUR packages in this module as, particularly for specific hardware, I rely on AUR to get the system functioning 100%. I have the code in place to do this and many AUR packages work well during install from a plain Arch ISO and a custom profile. In some cases, during the installation of a aur-test profile, I am encountering hundreds of the following errors once I hit the makepkg on weechat-git in my aur-test profile (as sourced below). It happens during git cloning in makepkg, so I thought it might be cache related? Buffer I/O errors sprinkled with an occasional EXT4-fs This should not happen!! I can reproduce this in a virtual machine using the following commands after booting into a plain Arch ISO 2011.08.19 (the following should work for any of you as well; I'd welcome other testers of this): # aif -p partial-configure-network # aif -p http://github.com/altercation/figtree/raw/master/procedures/automatic \\ -c profiles/aur-test -a (the latter is of course all one command, -a is the flag to activate AUR package install for my module) I thought it might be related to running out of disk space because I was using the runtime /tmp directory and it wasn't mounted where I thought, but I've tested with running makepkg in /mnt/tmp as well with the same problem. Best regards, Ethan -- Ethan Schoonover es@ethanschoonover.com -- Precision Colors - Solarized - http://ethanschoonover.com/solarized