| 1 |
On 08/17/2011 10:03 AM, Michał Górny wrote: |
| 2 |
> On Wed, 17 Aug 2011 10:19:06 +0200 |
| 3 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 4 |
> |
| 5 |
>>>>>>> On Wed, 17 Aug 2011, Michał Górny wrote: |
| 6 |
>> |
| 7 |
>>> And isn't a random PROPERTIES value more fragile? If someone uses it |
| 8 |
>>> incorrectly, the results are undefined. With older PMs, results are |
| 9 |
>>> undefined. |
| 10 |
>> |
| 11 |
>>> While having empty SRC_URI and no DEFINED_PHASES guarantees that |
| 12 |
>>> the ebuild won't install a file. That's just per-def, nothing can |
| 13 |
>>> happen. |
| 14 |
>> |
| 15 |
>> Unfortunately, the inverse is not true. There are virtuals that |
| 16 |
>> define phase functions, see virtual/ruby-* for example. |
| 17 |
> |
| 18 |
> And that's another issue in the ebuild. It should be fixed so that |
| 19 |
> phase functions won't be exported in the first place rather than |
| 20 |
> redefining them. This way, PM could assume it doesn't need to execute |
| 21 |
> those at all rather than running dummy code. |
| 22 |
|
| 23 |
You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt |
| 24 |
that package manager developers will want to rely on these kinds of |
| 25 |
fragile assumptions. You thought that relying on the "virtual" category |
| 26 |
name was ridiculous, but this SRC_URI + DEFINED_PHASES approach seems |
| 27 |
must less practical to me. |
| 28 |
-- |
| 29 |
Thanks, |
| 30 |
Zac |
Archives