Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Wed, 04 Nov 2009 08:26:11
Message-Id: 200911040926.06350.patrick@gentoo.org
In Reply to: Re: [gentoo-dev] FEATURES use or misuse? by Sebastian Pipping
1 On Wednesday 04 November 2009 01:33:23 Sebastian Pipping wrote:
2 > Patrick Lauer wrote:
3 > > Calling EAPI is ... well ... I can't even think of a place to start to
4 > > explain how wrong it is. How on earth are you going to parse an eclass
5 > > that supports multiple EAPIs where one EAPI were to support features of
6 > > bash 4? The only way to do it would be to force bash 4 on all lower
7 > > EAPIs, or make per-EAPI eclasses, or forbid use of new bash features in
8 > > eclasses. All horrible ways to avoid fixing the problem.
9 >
10 > I find restricting the eclass to Bash 3 is a natural, maintainable
11 > approach to this. How would "fixing he problem" work from your
12 > perspective?
13 It doesn't :)
14 You can't use the "new" features in the "old" eclass, even with conditionals
15 separating the execution paths. Which means you'd have to either not use them
16 (which makes me wonder why we allow features when they can't be used).
17 Or you clone the eclass and now maintain the code in two places (wheee, bad
18 engineering!)
19
20 So we end up with a bad solution either way. There are some clean options, but
21 they tend to be a bit more complex. For example globally forcing minimum
22 versions (which makes upgrade paths a bit more interesting).
23
24 >
25 > > All workaroundable by just
26 > > accepting things as they are.
27 >
28 > What do you mean by "accepting things as they are"?
29
30 People have been doing things (in this case using bash 3.2 features) for a
31 long time (about a year now). Even when some people warned about the impact
32 noone cared.
33
34 So more and more these "illegal" features get used, and as there are no
35 sanctions for it (not even from QA!) they are accepted as allowed.
36
37 Fast forward and you have an informal standard (using += in ebuilds is ok)
38 that is agreed on by everyone. Yes, everyone, because when people pointed out
39 that it was a Bad Thing there was no reaction, no opposition, nothing.
40
41 So the Gentoo developer community agreed on it. The only thing not reflecting
42 that agreement is PMS. So we fix it.
43
44 Same with FEATURES variable. Been used for the last few years. Works.
45 Most reliable way to do a few things if you assume that users don't actively
46 try to break things. And instead of properly documenting it we pretend it
47 never happened?
48
49
50 > You have been talking of "accepting reality" repeatedly and I'm left
51 > wondering what you actually mean by that. I especially fail to see who
52 > is trying to conceal(?) reality and reality about what.
53 Ok,
54
55 from stable portage ebuilds:
56 RDEPEND=" [snip]
57 >=app-shells/bash-3.2_p17
58
59 from KDE eclass:
60 RESTRICT+=" test"
61
62 gentoo-x86/app-shells/bash $ ls -1 *.ebuild
63 bash-3.1_p17.ebuild
64 bash-3.2_p39.ebuild
65 bash-3.2_p48-r1.ebuild
66 bash-3.2_p48.ebuild
67 bash-4.0_p28.ebuild
68 bash-4.0_p33.ebuild
69 bash-4.0_p35.ebuild
70
71 So we can either dance around all day and pretend bash 3.0 still has any
72 relevance, or we stop the nonsense and tolerate reality as it is.
73
74 We can also pretend FEATURES never served a purpose and doesn't fix any
75 issues, then spend lots of time workarounding around working solutions because
76 we just declared them illegal.
77
78 I don't know how much time you have and what your priorities are, but I'm not
79 going to care about such a waste of time, and it goes very low on my list of
80 priorities. If there's a decision on this I doubt most devs will care much, so
81 anyone wanting to have the FEATURES use removed will end up having to do it
82 himself, against the resistance of package maintainers (don't touch my package
83 etc. etc.)
84
85 Have fun,
86
87 Patrick