1 |
On Tuesday 03 November 2009 18:27:46 Sebastian Pipping wrote: |
2 |
> Patrick Lauer wrote: |
3 |
> > Hi there, |
4 |
> > |
5 |
> > a while ago Thilo Bangert spent quite some time on filing lots of bugs. |
6 |
> > While I appreciate such QA efforts I don't agree with those bugs at all. |
7 |
> > |
8 |
> > All of these bugs were for the use of the FEATURES variable in ebuilds, |
9 |
> > which is a very convenient thing to work around issues. |
10 |
> > For example known failures with FEATURE="distcc" or funky things like |
11 |
> > test failures with FEATURES="userpriv" and so on. All other methods of |
12 |
> > expressing that are much more verbose and inherently sucky. |
13 |
> |
14 |
> What other methods are there? |
15 |
|
16 |
For distcc, you could try some random things like checking the CC variable or |
17 |
such. All inherently unreliable methods to guess if the FEATURE variable |
18 |
contains a certain string. |
19 |
|
20 |
Userpriv I've seen the funny idea to check if UID=0 and such. |
21 |
|
22 |
I'd guess for every FEATURE there's a similarly confused method to guess if it |
23 |
is enabled or disabled, instead of just checking the friggin variable. |
24 |
|
25 |
> |
26 |
> > One example of such a bug is |
27 |
> > https://bugs.gentoo.org/show_bug.cgi?id=278960 for those too lazy to |
28 |
> > search. |
29 |
> |
30 |
> For that very case I remember that "test" is a global use flag as well |
31 |
> and that therefore at least |
32 |
> |
33 |
> if hasq test ${FEATURES} ; then |
34 |
> [..] |
35 |
> fi |
36 |
> |
37 |
> has a cleaner use-flag-based equivalent. |
38 |
> |
39 |
> # euse -i test |
40 |
> global use flags (searching: test) |
41 |
> ************************************************************ |
42 |
> [- ] test - Workaround to pull in packages needed to run with |
43 |
> FEATURES=test. Portage-2.1.2 handles this internally, |
44 |
> so don't set it in make.conf/package.use anymore |
45 |
|
46 |
That's a creative way to use a side-effect to check. Assumes that the package |
47 |
uses that useflag though, what about the case where you want to conditionally |
48 |
change a file (or maybe delete it or whatever) in src_prepare when |
49 |
FEATURES="test" is set, but USE="test" is not needed? |
50 |
|
51 |
In short, stop complexifying things. |
52 |
|
53 |
> |
54 |
> > To quote: |
55 |
> > "FEATURES is a portage specific package manager configuration variable |
56 |
> > not specified in PMS and cannot reliably be used in ebuilds or eclasses." |
57 |
> |
58 |
> Makes sense to me atm. |
59 |
Makes no sense to me, but then I seem to be special :) |
60 |
|
61 |
> My opinion is: please stop dissing PMS, it doesn't help anybody. |
62 |
> I have requested that from you before. |
63 |
It's still broken. |
64 |
It doesn't document reality. |
65 |
It's not useful as an implementation guideline or as a reference how to do |
66 |
things. In short, it sucks badly. And all my attempts to get it fixed have |
67 |
been deflected, so I'll keep ridiculing it until it stops being a failwhale. |
68 |
|
69 |
After all I'm here to participate in the bestest distro ever, so we deserve |
70 |
correct and consistent documentation. |
71 |
|
72 |
> Would a patch for the next EAPI theoretically impossible? |
73 |
I absolutely fail to see how that helps the current situation. |
74 |
EAPI is not the right answer to every question. :) |
75 |
|
76 |
|
77 |
Have fun, |
78 |
|
79 |
Patrick |