Gentoo Archives: gentoo-project

From: "Anthony G. Basile" <basile@××××××××××××××.edu>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
Date: Fri, 05 Jul 2013 15:12:51
Message-Id: 51D6E2D7.6000003@opensource.dyc.edu
In Reply to: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014 by Arfrever Frehtes Taifersar Arahesis
1 On 07/03/2013 12:37 AM, Arfrever Frehtes Taifersar Arahesis wrote:
2 > Here is updated list of questions with fixes and added URLs.
3 >
4
5
6 Arfrever, thanks for the clarification on those questions. The bug
7 report helped. For what its worth, here are the rest of my answers:
8
9
10 09. Will you vote for including support for USE-flag-dependent slots in
11 EAPI 6
12
13 This would add support for syntax/semantics like this:
14
15 SLOT="multislot? ( $PV ) !multislot? ( 0 )"
16
17 I don't know about this one. My gut reaction is the same as Zac's, why
18 not just unconditionally do SLOT="$PV". I'm bothered by what it means
19 for a user who might later drop USE="mutlislot", would we clean up all
20 the older SLOTS? I'm going to say no to this one unless there's a more
21 pressing case made.
22
23 My general philosophy is to not just add features which address some
24 issue but think about what other (ab)uses it might lead to. I'm not
25 sure this one won't open up a can of worms.
26
27
28
29 10. Will you vote for including support for package.mask, package.use
30 and {,package.}use{,.stable}.{force,mask} directories in EAPI 6
31
32 Okay, I misinterpreted this one. Its a question of *directories* for
33 these vs flat files. I see no problem here.
34
35
36
37 18. Will you vote for including support for repository-specific
38 package.use and {,package.}use{,.stable}.{force,mask} in EAPI 6
39
40 Okay in my last answer set, I misinterpreted 10 and my answer there is
41 more relevant to 18 so let me briefly repeat it here: I have mixed
42 feelings about these configurations because they solve issues that occur
43 with deep profile stackings whereas I prefer to encourage shallow
44 profile stackings with orthogonal tweaks relegated to profile/features
45 which can safely be added at the top (end) of the stack eg.
46 profile/features/selinux.
47
48
49
50 15. Will you vote for enabling globstar shell option by default in EAPI 6
51
52 Yes. On several occasions I've found myself wanting to do a `find ${D}
53 -print` in some ebuild or script to locate, eg. .la files. This reduces
54 the need for the extra execution of find and does it in the shell. It
55 does required bash-4 so that needs to be approved first for this.
56
57
58
59 16. Will you vote for providing REPOSITORY variable in EAPI 6
60 17. Will you vote for including support for repository dependencies in
61 EAPI 6
62
63 I agree with Michał and Ulrich here. I don't want the behavior of
64 ebuilds to change depending on repository. Functional differences
65 should be reflected in USE flags. We should not be depending on which
66 repository the ebuild lives in.
67
68
69
70 19. Will you vote for including support for optional run-time dependencies.
71
72 I would vote Yes. I didn't know about glep 62 before but this is
73 definitely a good feature and I can already see its usefulness for some
74 packages I maintain where there would be useless rebuild if I were to
75 drop USE="perl". I can't see through the implementation details but if
76 the PMS people think this is doable, then yes. From a consumer point of
77 view, it has no backwards compat issues and adds a feature which is well
78 defined and useful.
79
80
81
82 20. Will you vote for including support for host/target-specific
83 dependencies in EAPI 6
84 21. Will you vote for including support for crosscompilation-specific
85 dependencies in EAPI 6
86
87 This is a tough one. Distinguishing host dependencies from target
88 dependencies is a legitimate issue and one which I've had to deal with
89 myself. However its clear from the discussion that there are semantic
90 issues revolving around the meaning of the proposed
91 DEPEND/TDEPEND/HDEPEND/BDEPEND etc. The discussion is approaching
92 clarity towards the end with Steve's and Mike's obersvation, and I'm
93 siding with the
94 BDEPEND approach, but I'm not sure we're ready for inclusion in EAPI 6.
95 A definite vote of "yes" for when its ready.
96
97 Incidentally the way I've dealt with this myself is always by manual
98 hacks, ie, I run a cross-emerge until it breaks, I see why it breaks, I
99 manually deal with the dependencies (or other issues). Since I'm
100 usually interested in just getting a seed to run catalyst on native
101 hardware, I can live with my approach, but this is a real show stopper
102 for a cross-emerge catalyst run. Given that native hardware can be
103 slow, we really want to get this fixed.
104
105
106
107 22. Will you vote for including support for DEPENDENCIES variable with
108 labels in EAPI 6
109 23. Will you vote for including support for labels in SRC_URI variable
110 in EAPI 6
111
112 I would not vote in favor of these. While the first one is interesting,
113 it deviates significantly from Gentoo's approach to dependencies and I
114 don't see how it would fit in. I'm less opposed to the second one,
115 alhtough I don't see usefulness. I don't like the label syntax, but
116 that secondary since we could work through that
117 if we wanted this.
118
119 General statement: I'm not for radical changes which what I see in
120 queston 22. We do sometimes engineer ourselves into a corner and we
121 have to struggle with that (eg. the meaning of *DEPEND in the previous
122 question), but radical changes just means we engineer ourselves into
123 dirrent corners while loosing what we've already done.
124
125
126
127 24. Will you vote for exporting XDG_CACHE_HOME, XDG_CONFIG_HOME,
128 XDG_DATA_HOME and XDG_RUNTIME_DIR variables (with useful values) in EAPI 6
129
130 I'm with Zac on this one. Why not do this in an eclass? So "no" unless
131 there's some mitigating reason why it can't be done elsewhere.
132
133
134
135 25. Will you vote for including support for unique subslots for live
136 ebuilds in EAPI 6
137
138 This one is amusing. -9999 are wild moving targets in the first place.
139 subslots are for when ABIs change in libraries without corresponding
140 SONAME bumps, so this makes for an interesting combination.
141
142 I have no strong feelings against it since live ebuilds are not for end
143 users but developers. If you emerge one, then its up to you to know
144 what you are doing. Having said that, I can see how the subslotting
145 might be helpful to us.
146
147 Aside: I'm not much of a fan of subslotting. The situation where
148 upstream changes ABIs without bumping SONAME represents a bug in the
149 library which should not accommodate by a feature in our PMS.
150
151
152
153 26. Will you vote for including support for transitive subslots in EAPI 6
154
155 Given that subslotting is used to track library version dependency, I
156 agree with Sergei's example. I would support this but I'd like to
157 eventually see the final details how this will be implemented.
158
159
160
161 27. Will you vote for including support for subslot dictionaries in EAPI 6
162
163 I had no idea about the independant bumps in the different ABIs of
164 app-text/poppler. I see the point to the need for this now. I'm torn
165 between the solution proposed by Arfrever (subslot dictionaries) and
166 that by Zac (use of virtuals). Zac's approach has the advantage that we
167 don't introuce a new (abusable?) feature to the package specs. Either
168 way, packages like poppler are going to be maintenance burdens on
169 maintainers who want to track the different internal ABI changes. This
170 is pitted against the current situation where users may be subjected to
171 unnecesary rebuilds. *shrug* I'm not sure which side is the lesser evil.
172
173
174
175 28. Will you vote for including support for ico, svg, xhtml and xml files in
176
177 Yes. Responding to points made in the bug: I say we include .ico files.
178 I have no strong opinions against backporting this with the -A or just
179 including it in EAPI 6.
180
181
182
183 29. Will you vote for disallowing diropts(), docompress(), exeopts(),
184 insopts(), keepdir(), libopts(), use(), use_enable(), use_with(),
185 useq(), usev() and usex() functions in global scope in EAPI 6
186
187 This sounds like a good idea but I have to be honest, I'm not sure what
188 problems it might introduce. So without doing an analysis of the tree
189 right now, I'm going to say a soft "yes" contingent on gathering more
190 information about what the consequences would be.
191
192
193 30. Will you vote for including support for src_fetch() function in EAPI 6
194
195 I'm not sure about this one. Why can't the problem in bug #249086 not
196 be solved in other ways? What other uses would there be for a
197 src_fetch()? (The only uses coming to mind are stuff like `use amd64`
198 for arch specific fetches but we can already do that.)
199
200 Also, I would be afraid of abuses, like live ebuild style fetching.
201 Repository history can be rewritten, so just because you set a commit
202 tag, doesn't guarantee stuff won't change on you. I know this can and
203 does happen with tarballs too, but I'd like to see QA checks in any
204 implementation of src_fetch() against the kind of upstream changes that
205 can occur in repositories.
206
207
208
209 31. Will you vote for including support for "." characters in package
210 names in EAPI 6
211 32. Will you vote for including support for "." characters in USE flags
212 in EAPI 6
213
214 I have no strong feelings either way. If people want this and it isn't
215 an implementation nightmare then okay.
216
217 USE=i.can_t.wait.to.see.how.this.one.will.be.abused
218
219 The only negative I can think of right now is that this may clash with
220 future semantics we may want to attribute to "." in either of those two
221 contexts. Like what if we want to formalize some meaning to sub-use
222 flags as a better namespace approach rather than USE_EXPAND?
223 USE="plugin.auth plugin.liana" I don't know, just thinking out loud.
224
225
226 --Tony
227
228
229 --
230 Anthony G. Basile, Ph. D.
231 Chair of Information Technology
232 D'Youville College
233 Buffalo, NY 14201
234 (716) 829-8197