[arch-releng] figtree - AIF module for version controlled config trees

Ethan Schoonover es at ethanschoonover.com
Fri Sep 2 14:51:08 EDT 2011

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



  * 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 Schoonover
es at ethanschoonover.com
Precision Colors - Solarized - http://ethanschoonover.com/solarized

More information about the arch-releng mailing list