Joe Di Pol wrote: > > Bart, > > My original reaction to this was "Oh, great. Two more IPS specific > concepts I need to get my head around". But after thinking > about it I'm hoping this ends up getting mapped in a general fashion > to the (possibly enhanced) tag/filter mechanism. > > Is the intent to define a new syntax for specifying facet/variant > "filters"? I.e. something like this (using cfg_cache): > > [selector] > variant.arch=sparc > facet.locale=en_US.UTF-8 > > I'd be concerned with that. This is ambiguous, and requires that > you understand how variants and facets work and interact in order > to know what this "filter" does. I'd prefer building off the > existing tag/filter syntax like this: > > [filter] > variant.arch=sparc & facet.locale ~ en_US.UTF-8 > > where facet.locale is a tag with a list value and "~" means contains > (or overload "=" if that was deemed more appropriate). These would > be enhancements to the current tag/filter implementation. This is more > explicit which I like, and variants and facets become ways of using > tags as opposed to entirely new things with their own behavior and > syntax.
The filtering mechanism is very powerful, but does not let the package developer/publisher express the useful and tested subsets of their package(s). Such a mechanism is essential, I think. Secondly, the need for the package developer to constrain the installation permutations to tested configurations requires that tags and variants always be used in the same fashion. I see client-side filtering as a "you're off the reservation" mechanism in terms of the resulted installed configuration. So I look to the implementation of facets and variants to constrain their usage to accepted norms. You can also filter on tags and variants, obviously. We may well implement tags and variants as filters... but I want a separate interface from filters for the definition of what facets & variants are set on the image. - 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
