| 1 |
On 2021-03-30 Tue 02:18, Ulrich Mueller wrote: |
| 2 |
> So yes, maybe we should have a separate spec for forward-compatible |
| 3 |
> repository features that are independent of EAPI. But I think that |
| 4 |
> incompatible changes won't be possible there and would have to reamin |
| 5 |
> in PMS. (For example, updating of package dependencies in profiles from |
| 6 |
> EAPI 0 to EAPI 5 was not forward compatible and required the one year |
| 7 |
> waiting period.) |
| 8 |
|
| 9 |
My main point is if users expect repos leveraging these features to work |
| 10 |
with most tools it would be helpful to document them in a more |
| 11 |
canonical, visible location than man pages and probably discuss them |
| 12 |
more visibly as well. If they were truly optional features it wouldn't |
| 13 |
be as much of an issue, but an increasing number of complex overlays |
| 14 |
assume a minimum of portage-1/portage-2 profile-formats features being |
| 15 |
readily available. |
| 16 |
|
| 17 |
Furthermore, I don't think the current spec even mentions the |
| 18 |
metadata/layout.conf file (and its semi-standard fields) and only |
| 19 |
passingly mentions overlays but has no details about them. Getting more |
| 20 |
of that in an official document would help devs know what they have to |
| 21 |
implement to support current repo/overlay functionality. |
| 22 |
|
| 23 |
Finally, pinning repo features to a standardized version allows tools to |
| 24 |
more readily report why they won't work when failing to meet the repo's |
| 25 |
required EAPI/RAPI instead of the semi-random errors that will often |
| 26 |
occur during unimplemented usage. |
| 27 |
|
| 28 |
Tim |
Archives