Binary System

I know I was advocating a significantly more complicated version earlier, but now this makes far more sense: We have a master system image for each class of machine, each of which is kept up to date via debian meta-packages. i.e. we have a login machine class, a mailserver class, etc, each of which is represented by one of the AFS volumes. This avoids all the tricky stuff like adding dependencies into some kind of fancy AFS automount. To keep the volumes up to date, we install debian meta-packages on each volume for the jobs they're supposed to perform. For example, all machines might have a "ugcs-basics" and "login-system" meta-package, which would consist of some doctored, some not-doctored packages from our package server. The mailserver would have a "mailserver" package installed in addition, etc. The result is that we would just have to maintain the meta-packages, and then could push the changes out to the machine just by doing a virtual upgrade on the volume. The pros: MUCH simpler than the old strategy I was advocating, doesn't require us to write a dependency handler, faster because it doesn't require multiple-volume mounts or DYNROOT configuration. The cons: More redundant space usage, less flexibility. We can't allow users the ability to pull in arbitrary packages as easily, so we'd have to go back to the old way where they request them and we add them, b/c they can't just do an overlay mount. Rationalization of cons: We've got n terabytes, any given system configuration shouldn't exceed 5 gb, so the redundancy should not be a major hinderance. Us reviewing apps users want is probably better anyways and more likely to work in the long run.

What do you guys think?