We're interested in xhiering several new arches, but we don't have much expertise between us. Dave says there's no formal xhier training, so he'd like to use this to bounce things off us for tutorials and such perhaps for staff meetings.

Guoxiang - Solaris 10, Daniel - AMD 64 Linux, Mike - FreeBSD, Chris - RedHat Linux.

Dave: let's discuss hardware - we all have appropriate bits, although Chris will need to talk to Jim. Dave says he can get stuff for Chris if he needs it.

We'd like to do two hours a week, maybe Mondays 1400-1600h. Everybody thinks that sounds ok. We'll try that for the next 4 weeks - Daniel will bookit for us.

Dave: everybody understands the regions concepts -

1. share - hosted on capo most of the time, or grep access-rights for a program to see if it comes from elsewhere
2. arch - hosted on archmaster most of the time
3. admin - all files controlled by an administration group
4. regional - all machines where uid is meant to be same everywhere, generally user has consistent home directory and email account. But you can limit this so a user doesn't have access to the machine - ie, teaching lab machines or the web.* servers
5. local - supposed to be sacrosanct but aren't always (very annoying!)

Lawrence: can one have different arch-specific admin files? Dave says one would have a softlink in the admin tree pointing to the arch tree, and the name of the file must exist under all arches.

Example: admin/dependencies, where the deps may vary based on the architecture. This would then be a link to arch.

Philosophy: name of file must exist under all arches because one xhier goal is "homogeneous look and feel across all architectures."

xhier/data/admin/requests : Dave wants to create a new concept (but this is argued over) - he'd like to make a requests-obsolete file. First thing one does when xhiering a new host is to say "don't include requests-obsolete requests because they're only around for historical reasons". This could be arch-dependent: some hosts still require something, but some don't. This idea is a problem for some because the more stuff in arch, the more figuring out needs to go on when porting to a new arch.

Philosophy: arch/ should contain the minimal amount of configurations as is necessary, because each needs to be re-ported for new architectures.

In xhier inheritance tree: where does arch fit in? Between share and admin? That's the generally accepted place.

Problems arise when a piece of software is included as part of the OS - perl, in particular. Dave thinks we should make perl vendor packages for such instances (debian31). Mike had originally suggested cover as part of the name, but Bill and Dave think that's incorrect (and Mike isn't/wasn't particularly attached to the name).

(Also how do you handle perl packages which requires a particular version, especially if there is more than one perl installed? This is an ongoing debate).

Moving on: 3 basic packages, xhier, os-extras, and mfcf-basics. We'll try to beat these into shape on the arches we're interested in, so that they install cleanly. Even for architectures that aren't binary-compatible with an existing arch.

Dave says we can do this by getting Makefiles from capo and then smooshing them down to the new archmaster.

Maybe we can come out of these meetings with some recommendations for revamping xhier.

For next Monday: we should have a bare OS install which we can get to via wireless. We should also prep by looking at xhier,dev and config bits of xhier.

Problems arise when trying to resolve conflicts between config and data types. Dave asserts stuff under data is supposed to be generated; stuff under config is meant to be edited by sysadmin by hand. However, he will look this up for next time.