| 1 |
On Tue, Aug 21, 2018 at 9:21 PM Thomas Deutschmann <whissi@g.o> wrote: |
| 2 |
> |
| 3 |
> On 2018-08-21 18:23, Michał Górny wrote: |
| 4 |
> >> Wait, are you saying that I can set USE=-test while FEATURES=test is |
| 5 |
> >> enabled? Is that a valid combination? |
| 6 |
> > |
| 7 |
> > Yes. |
| 8 |
> |
| 9 |
> The only thing I still don't understand yet: Do we support things like that? |
| 10 |
> |
| 11 |
> I.e. should we add things like |
| 12 |
> |
| 13 |
> > if has test ${FEATURES} && ! use test ; then |
| 14 |
> > eerror "FEATURES=test requires USE=test." |
| 15 |
> > die "FEATURES=test set but not USE=test" |
| 16 |
> > fi |
| 17 |
|
| 18 |
You should never look at FEATURES in an ebuild; it is not defined in |
| 19 |
PMS and is very Portage-specific. |
| 20 |
|
| 21 |
> if a package's src_test phase requires some conditional stuff or is it |
| 22 |
> something like "user shoot himself into the foot" so we do *not* care |
| 23 |
> because we still assume "if FEATURES=test, USE=test is *normally* set"? |
| 24 |
|
| 25 |
Ebuilds should be adjusted to not depend on FEATURES=test matching |
| 26 |
USE=test. Setting RESTRICT="!test? ( test )" is generally sufficient. |
| 27 |
|
| 28 |
> Asking from user experience point of view: Imagine a user tries to |
| 29 |
> emerge a package which will compile multiple hours and src_test just |
| 30 |
> fails because some conditional stuff didn't run due to USE=-test |
| 31 |
> accidentally set by the user (in the past or was forgotten). |
| 32 |
|
| 33 |
What user is going to set FEATURS=test and USE=-test? It's such a |
| 34 |
silly thing to worry about. |
| 35 |
|
| 36 |
Please stop inflating the scope of the issue. |
Archives