1 |
Zac Medico wrote: |
2 |
|
3 |
> As a substitute for the previously discussed RESTRICT=live value[1], |
4 |
> I'd now like you to consider an equivalent PROPERTIES=live-sources |
5 |
> setting. By specifying PROPERTIES=live-sources, an ebuild will be |
6 |
> able to indicate that it uses src_unpack() to download sources from |
7 |
> some type of live repository such as cvs, darcs, git, mercurial, or svn. |
8 |
> |
9 |
VCS="cvs|svn.." seems a lot cleaner, expressing simply that the ebuild _can_ |
10 |
download its sources. Whether that's to a specific release, a rolling |
11 |
upgrade, a 'oneshot latest' etc is up to the _user_, expressed via any of |
12 |
the existing mechanisms. A simple map of vcs to eclass (in a config file |
13 |
somewhere, system wide and repo-specific spring to mind) means the manager |
14 |
wouldn't have to change to handle a new version control system, given a |
15 |
sane base API. |
16 |
|
17 |
> However, numerous people has expressed a desire to |
18 |
> have a new variable to represent a different category of boolean |
19 |
> attributes, so as not to pollute the RESTRICT variable with values |
20 |
> that don't fit well into existing RESTRICT nomenclature conventions. |
21 |
> |
22 |
|
23 |
Seems useful as a way to introduce variables which might later be promoted |
24 |
to more than a simple 'presence=yes'-type, akin to py 'future' |
25 |
|
26 |
Thanks for all your hard work; 2.2 has proven to be worth the wait, and |
27 |
seems to be moving quickly. |