FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-13-2012, 03:24 PM
Ciaran McCreesh
 
Default USE_EXPAND / USE 'configuration space' refactoring: bikeshedding the separator

On Thu, 13 Sep 2012 03:39:19 -0700
Brian Harring <ferringb@gmail.com> wrote:
> 1) We disallow '@' in USE flags (yes, a use flag can actually have
> '@' in it's name according to PMS; someone was hitting the crack
> pipe pretty damn hard when they allowed that one). This doesn't
> impact anything in gentoo-x86, nor any tree I've ever seen.

No crack pipe was involved in that decision! It's because of LINGUAS.

(Incidentally, we used : rather than @ for separation for exheres-0 for
that reason.)

--
Ciaran McCreesh
 
Old 09-13-2012, 05:53 PM
Brian Harring
 
Default USE_EXPAND / USE 'configuration space' refactoring: bikeshedding the separator

On Thu, Sep 13, 2012 at 04:24:27PM +0100, Ciaran McCreesh wrote:
> On Thu, 13 Sep 2012 03:39:19 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > 1) We disallow '@' in USE flags (yes, a use flag can actually have
> > '@' in it's name according to PMS; someone was hitting the crack
> > pipe pretty damn hard when they allowed that one). This doesn't
> > impact anything in gentoo-x86, nor any tree I've ever seen.
>
> No crack pipe was involved in that decision! It's because of LINGUAS.
>
> (Incidentally, we used : rather than @ for separation for exheres-0 for
> that reason.)

Who says Linguas definition didn't involve a bit 'o crack? On that
subject, not entirely sure how the hell a grepp'ing of profiles on my
part missed that file; worse, I distinctly recall this coming up in
the past. Suspect it's time we add a footnote to that section of
names since it's non-obvious. Sigh...

Two angles;

1) Mind you, the woken up/caffeine ratio currently blows so this
could be quite off kilter- but at first glance the '@' linguas usage
actually seems to map to sub use groups (both in intent and
grouping), at least for the quick scan I did of what we use. Might
not actually be an issue, iow if we allow that, although that's
assuming the '@' subgroup approach translates reasonably cleanly.

The potential failure I'd see with that approach is it's a bit reliant
on the assumption that the rules:

`language[_territory[.codeset]][@modifier]`

have been abided by- that the modifier is just that, a modifier.
Were we to do this, which, at least at first sight, seems like a nifty
solution that addresses it, we'd *likely* want sub groups to have a
rule such that if you try to expand the subgroup of a setting, and
that setting isn't a subgroup, it is considered 'on'. Basically, for
the linguas case, it kind of sucks if we get into the situation where
the consuming ebuilds/eclasses has to be sensitive to which modifiers
were exposed. Essentially:

linguas@de_DE@, if not a subgroup to expand to, is treated as scalar,
rather than list. Impliciations of that I've not yet fully thought
out- note that tweak isn't necessary for the basic notion of #1 to be
usable also.


2) bikeshedding potentials: just spitballing a couple of potentials
if '@' subgroups there doesn't fly for folks reading (mean it nicely,
we shouldn't diverge arbitarily, but in the same instant we shouldn't
import syntax/notions from exherbo unless they explicitly make sense
in the gentoo/PMS context; the formats diverge enough the "reuse for
compatibility" argument doesn't hold much water):

ruby_targets@ruby_18
ruby_targets:ruby_18
ruby_targets|ruby_18
ruby_targets(ruby_18)

Potentially fun thought, although the syntax is kind of ugly;
basically we treat 'ruby_target' as a matching target (restriction in
pkgcore vernacular, something that matches something else); the nice
thing about this is it naturally plugins into the notion of multiple
settings:

ruby_targets[ruby18]
ruby_targets[ruby18,ruby19]

In the same angle, while it's partially valid bash (and not in the
single setting case):
ruby_targets{ruby_18}
ruby_targets{ruby_18,ruby_19}

That said, I consider the [] and {} syntax absolutely freaking ugly to
the eye. I mention it should others think it's not butt-fugly.

If approach #1 doesn't fly, using ':' as the delimiter gets my vote.

~harring
 

Thread Tools




All times are GMT. The time now is 03:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org