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.
