| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Donnie Berkholz wrote: |
| 5 |
> On 13:39 Sat 23 Aug , Zac Medico wrote: |
| 6 |
>> Please consider a PROPERTIES=live value that, when set in an ebuild, |
| 7 |
>> will serve to indicate that the ebuild will use some form of "live" |
| 8 |
>> source code that may vary each time that the package is installed. |
| 9 |
>> The intention is for PROPERTIES=live to have a relatively pure and |
| 10 |
>> simple meaning. Therefore, the definition is intentionally more |
| 11 |
>> narrow than the definitions previously suggested for the related |
| 12 |
>> RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the |
| 13 |
>> future we may add additional (orthogonal) properties to represent |
| 14 |
>> other things like locking [3]. |
| 15 |
> |
| 16 |
> Here's what I'd like to see from this whole PROPERTIES discussion. |
| 17 |
> |
| 18 |
> - Are the PROPERTIES more fine-grained than they need to be? |
| 19 |
> - Are the common use cases specifiable by a single PROPERTIES setting |
| 20 |
> that may actually do multiple things on the back end? |
| 21 |
|
| 22 |
Sure, we can add addition properties that have compound meanings. |
| 23 |
However, I'm pretty satisfied with the "pure and simple" form that |
| 24 |
I've suggested for the live, virtual, and interactive properties. |
| 25 |
Their purity makes them narrow in a way, but also broad in the sense |
| 26 |
that they will usable for a maximum number of ebuilds without any |
| 27 |
deviation from the official meaning. |
| 28 |
|
| 29 |
> If there's actually reasons for these things to be very narrow, I'd like |
| 30 |
> to see easily usable meta-properties that let people easily say |
| 31 |
> something like "I've got a live CVS ebuild" without specifying 20 |
| 32 |
> different PROPERTIES. |
| 33 |
|
| 34 |
For a cases like this, we can define a "live-cvs" property that |
| 35 |
implies the "live" property. By defining compound properties in this |
| 36 |
way, we can avoid things like PROPERTIES="live live-cvs" since |
| 37 |
"live-cvs" alone will also imply "live". As such, it would be |
| 38 |
redundant to set PROPERTIES="live live-cvs" when |
| 39 |
PROPERTIES="live-cvs" would have identical meaning. |
| 40 |
- -- |
| 41 |
Thanks, |
| 42 |
Zac |
| 43 |
-----BEGIN PGP SIGNATURE----- |
| 44 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 45 |
|
| 46 |
iEYEARECAAYFAkiy8AgACgkQ/ejvha5XGaOnuQCg7up9Pw0nIgtg8GvKgTj2KHKn |
| 47 |
VKwAoJ5xfKpaYEn8Z5u1ly7ELHoh+t3N |
| 48 |
=4tZZ |
| 49 |
-----END PGP SIGNATURE----- |
Archives