On Mon, Dec 01, 2008 at 03:16:05PM -0800, Bart Smaalders wrote: > Name values > -------------------------------------------- > facet.l10n zero or more of en_US, de, ...
Hm. So I would expect an implicit value of "C" here (which would, by default, eliminate all other l10n facet values). I'm not sure that we want to allow zero values in a multi-value facet. Perhaps I'm not being creative enough in my thinking? > An action that is tagged w/ a facet or variant that is not selected > will be automatically excluded; Hm. There probably ought to be a way to specify all facet values. I'd been thinking of doing it the way filters do it -- by not specifying the facet filter at all, which would pull in (say) all localizations. That would certainly make the facet -> filter mapping easier, and we could put syntactic sugar in to make a facet accept "*" as ignoring the facet. Obviously this is meaningless for variants, which I'd always assumed would be forced into a single value by the -- eventual -- inclusion of a rule that disallows non-unique actions. > actions w/o facets or variants are always included. A single action may > have multiple facet and variant tags; an example would be an > architecture-specific header file that's used by developers: > > file 8e7247b269fd116345abbf1aa9000a3d81ed871b > chash=1fe53e8e2d0ad25bae13e1fd622c50397a2389ce group=bin mode=0644 > owner=root path=usr/include/sys/regset.h variant.arch=x86 > facet.devel=true pkg.csize=4002 pkg.size=12457 Might want to point out that while this is a useful example, a better answer in this particular case is to eliminate architecture-specific architecture-independent files. :) Another thought -- it'd be nice for, say, the Russian (ru) l10n facet value to automatically bring in SUNWlang-ru, without having to specify the dependency in the faceted package. Otherwise, you end up having to specify a dependency that itself is protected by a facet. > In order to simplify grouping of facets, wildcarding is supported > when setting image or package facets, but not variants. For example, > facet.doc.* matches facet.doc.man, facet.doc.info and facet.doc.html. > Similarly, setting facet.*=* will match all facets, installing > developer software, documentation and all available locales, and > any other optional components. Hm. Perhaps "facet.doc == true" could imply "facet.doc.man == true" unless the latter is explicitly set to false? That is, drop the "*"? Would there be any other meaning to "facet.doc"? > Name Values > ----------------------------------------------------- > facet.l10n en_AU.UTF-8, en_US.UTF-8, ... One thing that I never got around to implementing for filters was the notion of "fallbacks". That is, you could specify "en_AU.UTF-8", but if that wasn't available for a package and "en_AU" was, it'd pull in the latter. And if "en_AU" wasn't in the package, then it'd pull in "en". I think that'd be a useful concept. We could implement short-circuiting OR and set up "macros" of some sort to do that work. It might also be useful to think of the other slices in the localization space -- perhaps you're interested in all localizations, but only if they're UTF-8. Or maybe all Canadian locales, regardless of whether they're English or French (or, um, Chinese or Urdu). > facet.devel true This will be a tricky one, particularly wrt DTrace -- header files are needed there for non-developer operation. How do we facet that? We could say that DTrace is a developer thing, but I'll let you wrestle Brian, Mike, and Adam for that. :) We could just give up on header files, particularly because they're small, so who cares. Or maybe we come up with a new facet that's DTrace-specific (are there any other kinds of files it needs)? > Since previous installations have implicitly included all facets, Will opensolaris.zone become a facet as well, or will it remain a simple filter? Also, you don't talk about self-describing facets and variants yet -- how does a package maintainer introduce a new facet or variant that allows itself to be described properly in a UI without changing code in all the UIs that deal with these constructs? And a terminology question. Which is the facet for a package -- "facet.l10n" or "facet.l10n == en_AU.UTF-8"? That is, when talking about multivalued facets, do we talk about the localization facet of a package, or the Australian localization facet of a package. I used "facet value" above, but wasn't sure if that's how you were thinking. Thanks, Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
