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 |