1 |
On Thu, Sep 13, 2012 at 04:24:27PM +0100, Ciaran McCreesh wrote: |
2 |
> On Thu, 13 Sep 2012 03:39:19 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > 1) We disallow '@' in USE flags (yes, a use flag can actually have |
5 |
> > '@' in it's name according to PMS; someone was hitting the crack |
6 |
> > pipe pretty damn hard when they allowed that one). This doesn't |
7 |
> > impact anything in gentoo-x86, nor any tree I've ever seen. |
8 |
> |
9 |
> No crack pipe was involved in that decision! It's because of LINGUAS. |
10 |
> |
11 |
> (Incidentally, we used : rather than @ for separation for exheres-0 for |
12 |
> that reason.) |
13 |
|
14 |
Who says Linguas definition didn't involve a bit 'o crack? ;) On that |
15 |
subject, not entirely sure how the hell a grepp'ing of profiles on my |
16 |
part missed that file; worse, I distinctly recall this coming up in |
17 |
the past. Suspect it's time we add a footnote to that section of |
18 |
names since it's non-obvious. Sigh... |
19 |
|
20 |
Two angles; |
21 |
|
22 |
1) Mind you, the woken up/caffeine ratio currently blows so this |
23 |
could be quite off kilter- but at first glance the '@' linguas usage |
24 |
actually seems to map to sub use groups (both in intent and |
25 |
grouping), at least for the quick scan I did of what we use. Might |
26 |
not actually be an issue, iow if we allow that, although that's |
27 |
assuming the '@' subgroup approach translates reasonably cleanly. |
28 |
|
29 |
The potential failure I'd see with that approach is it's a bit reliant |
30 |
on the assumption that the rules: |
31 |
|
32 |
`language[_territory[.codeset]][@modifier]` |
33 |
|
34 |
have been abided by- that the modifier is just that, a modifier. |
35 |
Were we to do this, which, at least at first sight, seems like a nifty |
36 |
solution that addresses it, we'd *likely* want sub groups to have a |
37 |
rule such that if you try to expand the subgroup of a setting, and |
38 |
that setting isn't a subgroup, it is considered 'on'. Basically, for |
39 |
the linguas case, it kind of sucks if we get into the situation where |
40 |
the consuming ebuilds/eclasses has to be sensitive to which modifiers |
41 |
were exposed. Essentially: |
42 |
|
43 |
linguas@de_DE@, if not a subgroup to expand to, is treated as scalar, |
44 |
rather than list. Impliciations of that I've not yet fully thought |
45 |
out- note that tweak isn't necessary for the basic notion of #1 to be |
46 |
usable also. |
47 |
|
48 |
|
49 |
2) bikeshedding potentials: just spitballing a couple of potentials |
50 |
if '@' subgroups there doesn't fly for folks reading (mean it nicely, |
51 |
we shouldn't diverge arbitarily, but in the same instant we shouldn't |
52 |
import syntax/notions from exherbo unless they explicitly make sense |
53 |
in the gentoo/PMS context; the formats diverge enough the "reuse for |
54 |
compatibility" argument doesn't hold much water): |
55 |
|
56 |
ruby_targets@ruby_18 |
57 |
ruby_targets:ruby_18 |
58 |
ruby_targets|ruby_18 |
59 |
ruby_targets(ruby_18) |
60 |
|
61 |
Potentially fun thought, although the syntax is kind of ugly; |
62 |
basically we treat 'ruby_target' as a matching target (restriction in |
63 |
pkgcore vernacular, something that matches something else); the nice |
64 |
thing about this is it naturally plugins into the notion of multiple |
65 |
settings: |
66 |
|
67 |
ruby_targets[ruby18] |
68 |
ruby_targets[ruby18,ruby19] |
69 |
|
70 |
In the same angle, while it's partially valid bash (and not in the |
71 |
single setting case): |
72 |
ruby_targets{ruby_18} |
73 |
ruby_targets{ruby_18,ruby_19} |
74 |
|
75 |
That said, I consider the [] and {} syntax absolutely freaking ugly to |
76 |
the eye. I mention it should others think it's not butt-fugly. |
77 |
|
78 |
If approach #1 doesn't fly, using ':' as the delimiter gets my vote. |
79 |
|
80 |
~harring |