1 |
>>>>> On Wed, 25 Jul 2012, Mike Frysinger wrote: |
2 |
|
3 |
>> Our current policy [1] requires that ebuilds must assign the seven |
4 |
>> variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, |
5 |
>> and IUSE, even if their value is empty. |
6 |
>> |
7 |
>> Could we drop this requirement? Repoman already enforces that |
8 |
>> DESCRIPTION, HOMEPAGE, LICENSE, SLOT, and KEYWORDS are non-empty |
9 |
>> (with some exceptions for virtuals). I don't see why we need to |
10 |
>> distinguish the "empty value" and "not assigned" cases. |
11 |
|
12 |
> i think we should clarify and say that when an eclass provides |
13 |
> these, the ebuild need not. completely missing DESCRIPTION/HOMEPAGE |
14 |
> should be a warning (and maybe KEYWORDS), and LICENSE should be an |
15 |
> error. there are plenty of examples of SRC_URI not being set and |
16 |
> that's fine (live ebuilds, ebuilds that only install out of |
17 |
> $FILESDIR, virtuals, etc...). |
18 |
|
19 |
I think we have to distinguish between PMS and tree policy here. |
20 |
The package manager should be able to handle any empty or missing |
21 |
variables (except for DESCRIPTION and SLOT). Otherwise we'd have to |
22 |
complicate the spec with additional case distinctions, e.g. for |
23 |
virtuals. |
24 |
|
25 |
On the other hand, tree policy (as enforced by repoman) wouldn't |
26 |
really change. In the cases you've mentioned above, it already |
27 |
displays errors or warnings. Repoman also doesn't distinguish between |
28 |
empty and unset variables. The single exception to this is IUSE, which |
29 |
is required to be present in an ebuild even if it's empty. Maybe we |
30 |
should drop this requirement, too. |
31 |
|
32 |
Ulrich |