Danek Duvall wrote: > 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? >
The C locale components, such as they are, are not optional and must be installed for many things to work correctly. As a result, it will always be installed, and not appear as a separate facet. Thus, setting facet.l10n (or for sch, locale) to 'C' in the image would result in no _other_ localizations being installed; it would do the right thing, however in that C would always be installed. >> 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. > Other than the '*' I proposed? Another possible mechanism is to implicitly match missing components: facet.= would match everything... facet.doc= would match facet.doc.html, etc. > 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. Yes... I'm still wondering about how to handle other variants, and making sure they get a rational default value. This is part of the self-describing problem you mention later... >> 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. :) heh; yes. A less ugly example might be a German locale version of some developer documentation. > > 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. > We're going down this path anyway with the entire incorporation, slim install and redistributable and the various architecture-specific driver packages, for example, unless we're going to install empty packages on other architectures, which I think is gross. One way to cope is to define a localizations package, that has the appropriate facets set on the various dependencies. This does leave us w/ the "how do I uninstall a package after changing locales problem", however. More thought needed... >> 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"? > I've been thinking along those lines as well. >> 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's not clear that the complications are worth it... why not set en_AU? Are the space savings significant? > > 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). > Well, we could implement a full regexp matching engine, but this is in a performance critical path as you know well. This is complicated, because such a facet would have implicit cross-action scope, and thus the code would have to grok which actions are equivalent except for their localizations, and then pick the most appropriate one. >> 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)? > We can tag such headers separately if we like... >> Since previous installations have implicitly included all facets, > > Will opensolaris.zone become a facet as well, or will it remain a simple > filter? > It could very easily become a facet... right now we don't have any files that install only in local zones... if such cases exist, and they intersect with global zone files, we would need to consider making the zone a variant. > 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? Still thinking about this; I'm concerned about needless replication and overloading... any ideas? I want to make this work as well but it's tricky. One mechanism would be to add set actions w/ the name == facet or variant to the package; these could also be tagged w/ facet.locale to support multi-lingual descriptions. We may want a better mechanism for this... > > 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. > I see a facet as an aspect of that package.... a particular file can have multiple locale facets (such as a input method used for several locales), an image can have multiple locales set... so I'm,included to refer to "Australian localization facet of a package". - 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
