Zac Medico wrote:

> As a substitute for the previously discussed RESTRICT=live value[1],
> I'd now like you to consider an equivalent PROPERTIES=live-sources
> setting. By specifying PROPERTIES=live-sources, an ebuild will be
> able to indicate that it uses src_unpack() to download sources from
> some type of live repository such as cvs, darcs, git, mercurial, or svn.
> 
VCS="cvs|svn.." seems a lot cleaner, expressing simply that the ebuild _can_
download its sources. Whether that's to a specific release, a rolling
upgrade, a 'oneshot latest' etc is up to the _user_, expressed via any of
the existing mechanisms. A simple map of vcs to eclass (in a config file
somewhere, system wide and repo-specific spring to mind) means the manager
wouldn't have to change to handle a new version control system, given a
sane base API.

> However, numerous people has expressed a desire to
> have a new variable to represent a different category of boolean
> attributes, so as not to pollute the RESTRICT variable with values
> that don't fit well into existing RESTRICT nomenclature conventions.
>

Seems useful as a way to introduce variables which might later be promoted
to more than a simple 'presence=yes'-type, akin to py 'future'

Thanks for all your hard work; 2.2 has proven to be worth the wait, and
seems to be moving quickly.