| 1 |
On Sun, May 17, 2020 at 7:44 PM William Hubbs <williamh@g.o> wrote: |
| 2 |
> |
| 3 |
> All, |
| 4 |
> |
| 5 |
> I have been acting as a backup maintainer for dev-vcs/cli. A pull |
| 6 |
> request was opened today that changes the way we detect whether the |
| 7 |
> ebuild is live from looking for "live" in $PROPERTIES to the version |
| 8 |
> number [1]. |
| 9 |
> |
| 10 |
> A different dev referred me to PMS which indicates that ebuilds should |
| 11 |
> not rely on $PROPERTIES for anything [2]. |
| 12 |
|
| 13 |
That's not what PMS says, and I think you are misinterpreting it. |
| 14 |
|
| 15 |
> I see quite a few ebuilds in the tree checking $FEATURES however, which |
| 16 |
> imo is even less reliable since $FEATURES is not specified anywhere in pms |
| 17 |
> and the $FEATURES variable is portage-specific. |
| 18 |
|
| 19 |
We don't really support checking FEATURES officially. It's a |
| 20 |
last-resort when no better option presents itself. |
| 21 |
|
| 22 |
> I guess I'm looking for consistency. If we are going to allow |
| 23 |
> $FEATURES to be checked, should we allow $PROPERTIES to be checked? Or, |
| 24 |
> should we ban checking both of them? |
| 25 |
|
| 26 |
Inspecting PROPERTIES is technically fine, but seems fairly useless to |
| 27 |
me. Its value is defined in ebuild code, so there's no "new" |
| 28 |
information to be gained from it. |
| 29 |
|
| 30 |
The code in dev-vcs/cli is broken: the "has" function takes a value |
| 31 |
list as separate arguments, but the ebuild is passing a single string |
| 32 |
to it. It is also done inconsistently: On line 10, it checks ${PV} == |
| 33 |
*9999, and then switches to checking ${PROPERTIES} later in the |
| 34 |
ebuild. I think it is better to use the same logic in both places. |
Archives