Not sure this thread is just sent to me instead of going to caiman-discuss. In any case, forwarding it there so everybody can see the discussion.
Please see my responses inline. On 02/02/10 15:33, Keith Mitchell wrote: > > > Volker A. Brandt wrote: >> [Sorry, meant to send this to the list as well. I'm currently in >> XML mode it seems :-)] >> >> Hi Karen! >> >> >> Forgive me for being late, and also forgive me for asking a question >> that >> might have been answered in another thread. >> >>> The changes I just pushed: >>> >>> Author: Karen Tung<Karen.Tung at Sun.COM> >>> Repository: /hg/caiman/slim_source >>> Latest revision: c6c48f08de33b0793ace03dc54036746548935a0 >>> Total changesets: 1 >>> Log message: >>> 12726 DC and installers shouldn't require a root password in the >>> packaged /etc/shadow >>> 12669 DC errors about /var/pkg/catalog >>> 12186 Deleting catalog cache needs to be revisited with with catalog v1 >> >> [...] >> >>> A optional configuration parameter is also added to the DC manifests. >>> This parameter >>> is being used by the new pre_boot_archive_pkg_image_mod.py >>> script. All DC manifests that builds the Slim CD and AI images are >>> updated >>> with this parameter. However, it is commented out: >>> >>> >>> <!-- >>> Password for the root user/role in the image. >>> If not specified, the default value of >>> "opensolaris" >>> will be used >>> --> >>> <!-- >>> Uncomment before using >>> <rootpass is_plaintext="true">plaintext-password</rootpass> >>> --> >> >> Why are these new elements added? On first glance, they might seem These new elements are added to allow users to specify a root password, if they wish, for the image they are constructing. They are done this way following the style of the rest of Distribution Constructor manifests. >> user-friendyl with their "descriptive" names. OTOH, it creates quite >> a bit more work when you want to validate or generate such manifests. >> Why is it more work to validate it? You define what you want to validate in the schema, and it will be taken care of. >> Wouldn't something like >> >> <dc_config> >> <entry> >> <key>rootpass</key> >> <value>plaintext-password</value> >> <attr>is_plaintext=true</attr> >> <attr>someotherattr=42</attr> >> </entry> >> </dc_config> >> >> or even better >> >> <dc_config> >> <entry> >> <key name="rootpass">plaintext-password</key> >> <attr name="is_plaintext">true</attr> >> <attr name="someotherattr type="int">42</attr> >> </entry> >> </dc_config> >> >> or even *gasp* an Apple-style property list be doing the same job? >> Such solutions would not require changing the DTD or schema every >> time, and would make maintaining manifest consumers and generators >> much easier. >> >> I mainly notice this while generating AI manifests for hands-off >> installations. This must have been discussed somewher before. >> Just wondering... > > Forgive me if I'm missing the obvious, but wouldn't that partially > defeat the purpose of having a schema in the first place? With the > suggested form, instead of changing the DTD/schema, you just have to > validate the content elsewhere, in a way that is less user friendly. Like Keith said, if we were to define them as key-value pairs, some other code will still have to validate it. For DC manifests, we already have a schema for defining manifest elements, and we also have the functionality there to validate and assign default values if needed. So, I choose to follow the same style. Thanks, --Karen > > Remember, the new elements are optional, so they shouldn't affect any > manifests that don't want/need to make use of the new feature. > > - Keith > >> >> Regards -- Volker
