| 1 |
On Thu, 19 Mar 2020 15:40:20 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> I'm not sure what you mean by "stabilization graph". I'm guessing you |
| 5 |
> mean the dependency graph for stable keywords? |
| 6 |
> |
| 7 |
> Valid dependency graphs are determined by whatever our tooling deems |
| 8 |
> valid. The tooling could be updated to permit amd64 packages to depend |
| 9 |
> on noarch packages, and vice-versa. |
| 10 |
|
| 11 |
No, its worse than that :/ |
| 12 |
|
| 13 |
If X is "noarch" and its dependency Y is "amd64", then a user on "sparc" |
| 14 |
will be able to install "X", but not its dependency "Y". |
| 15 |
|
| 16 |
And thus, the error from portage will: |
| 17 |
|
| 18 |
- Take longer to produce |
| 19 |
- Be less clear |
| 20 |
|
| 21 |
And any tooling that exposes "noarch" as "you can install this" will be |
| 22 |
wrong, because instead of the KEYWORDS being an independent declaration |
| 23 |
of usability, the entire dependency graph has to be checked for usability. |
| 24 |
|
| 25 |
Thus, end users will have portage erroring that a no-arch package is |
| 26 |
not available due to its dependencies being impossible to satisfy. |
| 27 |
|
| 28 |
And, as a QA measure, we'd have to make that condition illegal. |
| 29 |
|
| 30 |
And the only way to do that, would be for CI to reject packages that |
| 31 |
are "noarch" and depend on things that are in turn, not "noarch". |
Archives