| 1 |
>>>>> On Mon, 18 May 2020, William Hubbs wrote: |
| 2 |
|
| 3 |
> I have been acting as a backup maintainer for dev-vcs/cli. A pull |
| 4 |
> request was opened today that changes the way we detect whether the |
| 5 |
> ebuild is live from looking for "live" in $PROPERTIES to the version |
| 6 |
> number [1]. |
| 7 |
|
| 8 |
> A different dev referred me to PMS which indicates that ebuilds should |
| 9 |
> not rely on $PROPERTIES for anything [2]. |
| 10 |
|
| 11 |
PMS says that ebuilds may not rely on any package manager support for |
| 12 |
PROPERTIES. That doesn't prevent them (or eclasses) from assigning |
| 13 |
tokens to it, and of course it is perfectly legal to check for such |
| 14 |
tokens later in the ebuild. |
| 15 |
|
| 16 |
That said, current practice is to check for 9999 in PV. Maybe ebuilds |
| 17 |
could check for "live" in PROPERTIES instead, but presumably that should |
| 18 |
be discussed in gentoo-dev first and made a general policy if it would |
| 19 |
be accepted. |
| 20 |
|
| 21 |
> I see quite a few ebuilds in the tree checking $FEATURES however, |
| 22 |
> which imo is even less reliable since $FEATURES is not specified |
| 23 |
> anywhere in pms and the $FEATURES variable is portage-specific. |
| 24 |
|
| 25 |
> I guess I'm looking for consistency. If we are going to allow |
| 26 |
> $FEATURES to be checked, should we allow $PROPERTIES to be checked? |
| 27 |
> Or, should we ban checking both of them? |
| 28 |
|
| 29 |
> IMO if we allow $FEATURES to be checked, we really should reword PMS |
| 30 |
> to not say anything about $PROPERTIES other than to define the tokens |
| 31 |
> it can contain. |
| 32 |
|
| 33 |
In my understanding, ebuilds really shouldn't check FEATURES. If they do |
| 34 |
it nevertheless (sometime there's no other way), then there should be a |
| 35 |
non-catastrophic fallback. |
| 36 |
|
| 37 |
Ulrich |
| 38 |
|
| 39 |
> [1] https://github.com/gentoo/gentoo/pull/15851 |
| 40 |
> [2] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-670007.3.5 |
Archives