Peter Tribble wrote: > On Thu, Jun 11, 2009 at 10:01 PM, Ethan Quach<ethan.quach at sun.com> wrote: > >> The functional spec for AI derived manifests is posted at: >> >> http://www.opensolaris.org/os/project/caiman/auto_install/DerivedManifests/AI_derived_manifests_func_spec.txt >> >> I would appreciate and feedback comments. >> > > I'm having a little trouble visualising this. Do you have any samples > to illustrate > the behaviour? > > In particular, the definition given of a base manifest implies that > you're expecting > simple parameter substitution, with the derivation module presumably supplying > the values of the substituted parameters. How much control does that give you > in practice over the final manifest? >
No, I don't think we can simply provide derivation of just values. For example, the choice of whether or not to do mirroring of the target would require presence or absence of a complete chunk of specification, not just a value. So we will need to define derivation lines are, but I was thinking this to come out in the design. > In 3.2, that might be interpreted as saying that there's a 1:1 relationship > between a base manifest and a derivation module. I would expect to be able to > share - in particular I would expect to us the same derivation module > with multiple > manifests. Also, assuming I had a derivation module shared among > multiple manifests, > how would I update it so that all the affected services picked it up > without having to > manually update each one? > That's a good question. The current model of an install service and its manifests is that an internal copy is stored in the service, rather than a pointer to the location of the file. We're considering the same model for the derivation module, but not necessarily tied to it. thanks, -ethan
