Tom Mueller (pkg-discuss) wrote: > Bart, > > Interesting writeup - I like the facet and variant terminology. > I've been looking for some way of distinguishing between the two ideas that didn't require pre-defining things....
> Can you please explain how the facets and variants relate to the > existing filtering mechanism? Is this a complete replacement for what > we have now? Or are the facets and variants a subset of filters? If > so, what would be examples of other filters that are not facets or > variants? > I don't know yet. Obviously, we can implement facets and variants in terms of filters, but we may not want to expose the filtering mechanism. > Are facets always booleans? Or would we have a facet such as > "facet.lang=de" (vs. facet.lang.de = true) > Sure; either way works, we just have to pick one. I considered both. > Is there any mechanism for declaring valid facets for variants, with a > way of providing a text description of them? The list of available > facets/variants can be determined by examining the manifests, but there > doesn't appear to be a way to translate "facet.lang.de" into "German > Language". facets and variants are distinct, but I think I understand what you meant... the locale tags will likely follow something like rfc 4646. In the larger sense, we prob. need some way of adding a description for the use of guis, etc. >> >> Facets and variants are attributes, and as such can initially be >> set on any action, including dependencies, etc. This may need to >> be changed if it proves problematic. >> > Should this be "tags" rather than "attributes"? I had thought that we > were reserving the term attribute to refer to the thing that is set by a > set action. And that the tags are the name/value pairs on actions. Hmm. In the code, they're all part of the attr dictionary; we generally refer to those things as attributes. I'll take a look at the other docs. >> Facet and variants can be set at the image or package level. > Any thoughts at this point about how this would be done in the cfg_cache > file? Would the existing filter syntax be replaced? > Still mulling that over... > If facets and variants are set at the package level, how does this > interact with settings at the image level. For example, if I have > facet.lang.de set at the image level, and facet.devel set at the package > level for a package, will I get the German localization for the > developer files? Is the set of facets/variants for a package just the > union from the image and package settings with package override for > duplicates? As noted in the writeup, variants are ANDED together, and facets are ORED in the current proposal. If we use the lang tags as per your suggestion, and OR within a single facet and AND everything else, that would address this. For example: a file w/ facet.devel set and facet.lang=de would only be installed on an image w/ devel set and that locale enabled. But it would also be installed if face.lang=en_US was set in addition. Thanks - - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
