| 1 |
> The discussion is based on some questions that are hard to agree on: |
| 2 |
> |
| 3 |
> 1. How much of a problem is an unused USE flag in metadata.xml? |
| 4 |
|
| 5 |
Cosmetic issue. No functional impact. |
| 6 |
|
| 7 |
> 2. Should such repoman warnings be fixed? By whom? When? How? |
| 8 |
|
| 9 |
Yes. You see it, you fix it. |
| 10 |
|
| 11 |
Not fixing cosmetic issues (cf. compiler warnings) leads to more and |
| 12 |
more noise until real issues are just drowned in the noise; the only way |
| 13 |
to achieve excellence (in terms of quality) is discipline in adhering to |
| 14 |
rules and standards obsessively. |
| 15 |
|
| 16 |
If there are (too) many false positives we should add proper annotations |
| 17 |
to silence repoman ... |
| 18 |
|
| 19 |
> 3. Can USE flags actually be removed from stable ebuilds? |
| 20 |
|
| 21 |
Usually removing stable ebuilds makes useflags "disappear", rarely does |
| 22 |
masking stuff (e.g. old cups) lead to the disappearance of useflags as |
| 23 |
they would now be broken |
| 24 |
|
| 25 |
> 4. ... |
| 26 |
|
| 27 |
Do we need to discuss this? |
| 28 |
|
| 29 |
No. It's an amazing waste of time, almost as if we had no real problems |
| 30 |
to focus on. |
| 31 |
> |
| 32 |
> Because this can yield quite some bike-shedding; the alternative "out of |
| 33 |
> the box thinking" package.use.mask solution satisfies both parties, |
| 34 |
> which renders that discussion unnecessary. Nobody has objected this. |
| 35 |
|
| 36 |
That is a "fix" specific to this package alone, in the general case it |
| 37 |
is not valid. |
Archives