1 |
Am Donnerstag, den 09.04.2009, 04:51 +0300 schrieb Mart Raudsepp: |
2 |
> Hello, |
3 |
> |
4 |
> On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: |
5 |
> |
6 |
> > With eapis 1 and 2 we introduced nice features but also a couple of |
7 |
> > new |
8 |
> > problems. One of them are the use dependencies when the package you |
9 |
> > depend on doesn't have the use flag anymore (see [1] for an example). |
10 |
> > |
11 |
> > So I think it's time for a short eapi bump with some distinct |
12 |
> > improvements: |
13 |
> > |
14 |
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ |
15 |
> > |
16 |
> > |
17 |
> > Please discuss. |
18 |
> |
19 |
> |
20 |
> Sorry for getting my points of discussion on the details to the list so |
21 |
> late. |
22 |
> I have covered some of my concerns on the items in meetings and |
23 |
> otherwise on IRC, but now I'll try to get to them in further detail and |
24 |
> better wording to the mailing list. |
25 |
> |
26 |
> I'm going to go item-by-item here for the things I don't expect much |
27 |
> replies to, and then starting separate threads for those that I do. |
28 |
> |
29 |
> |
30 |
> pkg_pretend |
31 |
> =========== |
32 |
> |
33 |
> No objections. |
34 |
> Gives an intermediate step for handling USE flag combination |
35 |
> incompatibilities at pretend stage (to not find it failed in the |
36 |
> morning), yet has uses outside that as well. So, once there is a way to |
37 |
> express those kind of USE flag dependencies outside of pkg_pretend in a |
38 |
> better way in a future EAPI, pkg_pretend will still be useful for other |
39 |
> (less common) cases and can provide a description of the problem to the |
40 |
> user. |
41 |
> |
42 |
> |
43 |
> Use based deps with non-existing USE flags |
44 |
> ========================================== |
45 |
> |
46 |
> No objections. |
47 |
> Implements the missing bit of "built_with_use --missing" |
48 |
> Main driving force behind EAPI-3. |
49 |
> |
50 |
> |
51 |
> default src_install |
52 |
> =================== |
53 |
> |
54 |
> No considerable input yet, catching up with the latest thread about |
55 |
> src_install bikeshedding |
56 |
> |
57 |
> |
58 |
> doinclude |
59 |
> ========= |
60 |
> |
61 |
> Unnecessary. Might be interesting for automatic executable permission |
62 |
> removing, but upstream build systems should be fixed instead for such a |
63 |
> big and rare error. |
64 |
> |
65 |
> |
66 |
> ban dosed |
67 |
> ========= |
68 |
> |
69 |
> I don't exactly see a reason for the banning yet, but no objections due |
70 |
> to general agreement on it and having no technical objections |
71 |
> |
72 |
> |
73 |
> doins support for symlinks |
74 |
> ========================== |
75 |
> |
76 |
> Lacking information. Need to see if the PMS draft has anything about it. |
77 |
> The bug and summaries just talk about the support, but no details. Would |
78 |
> it be an argument to doins? |
79 |
> |
80 |
> |
81 |
> unpack failing on unknown types |
82 |
> =============================== |
83 |
> |
84 |
> Uncertain about it's worthiness. Might rather have the opposite with a |
85 |
> --strict argument kind of deal. No official objection from me. |
86 |
> |
87 |
> |
88 |
> docompress |
89 |
> ========== |
90 |
> |
91 |
> Need some more time to digest through it in relation to |
92 |
> PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before |
93 |
> meeting. |
94 |
> |
95 |
> |
96 |
> properties must be cached properly |
97 |
> ================================== |
98 |
> |
99 |
> No opinion, up to the package manager developers. |
100 |
> Don't see offhand why it should be an EAPI item at all. Feels like an |
101 |
> implementation detail. |
102 |
|
103 |
The metadata cache needs to be specified to make it work with compliant |
104 |
PM's and is therefore a part of the PMS. |
105 |
A change is therefore required to be done on a per-EAPI base. |
106 |
|
107 |
> |
108 |
> |
109 |
> DEFINED_PHASES must be supported (and cached properly) |
110 |
> ====================================================== |
111 |
> |
112 |
> No opinion, up to the package manager developers more or less. |
113 |
> Not sure why this needs to be an EAPI item. Hard to see a use case for |
114 |
> the variable being available for ebuild usage for it to be necessary to |
115 |
> be an EAPI item. |
116 |
> By my understanding it is (also?) a required implementation detail to |
117 |
> handle pkg_pretend sanely and with minimal time hit. |
118 |
> |
119 |
> |
120 |
> Limit values in $USE to ones in $IUSE: |
121 |
> ====================================== |
122 |
> |
123 |
> Seems more of a QA test, but forcing it can make it be caught at start. |
124 |
> Don't see why it must be an EAPI item. Just vet the tree of (future?) |
125 |
> repoman warnings about it and make it happen for |
126 |
> all EAPIs. Impact on overlays is minimal because it is a QA error to not |
127 |
> define them and they get what they asked for. |
128 |
> |
129 |
> Not strongly opposed to it being in the EAPI. |
130 |
> |
131 |
Why it has to be done in an EAPI: It matters whether you have to put for |
132 |
example userland_GNU in IUSE if you want to use it in the ebuild or not. |
133 |
|
134 |
|
135 |
> |
136 |
> --disable-dependency-tracking: |
137 |
> ============================== |
138 |
> |
139 |
> possible breakage of (custom) configure scripts that don't accept |
140 |
> unknown arguments. Would be nice to pass that for most packages, but |
141 |
> doing it always with econf seems slightly inappropriate, given the |
142 |
> above. |
143 |
> Don't think this is an item for fast-tracked EAPI-3. |
144 |
|
145 |
custom configure scripts mostly already break with econf, so not an |
146 |
issue. |
147 |
|
148 |
> |
149 |
> |
150 |
> utility commands should die by default |
151 |
> ====================================== |
152 |
> |
153 |
> Would like to see a list of those utility commands that would be made to |
154 |
> die by default. |
155 |
basically all do* commands. |
156 |
|
157 |
> |
158 |
> |
159 |
> ban || ( foo? ( . ) . ) |
160 |
> ======================= |
161 |
> |
162 |
> It is not the business of an EAPI to start disallowing *DEPEND string |
163 |
> constructs. |
164 |
It's EAPI's business to define what's valid and what is not. |
165 |
|
166 |
> There is no useful alternative provided yet to my knowledge and this is |
167 |
> really a QA issue, not an EAPI issue. |
168 |
The problem is that there is no valid use case to justify the existence |
169 |
of this construct. In either way users will most likely not have what |
170 |
they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will |
171 |
therefore help the user to get what the specified and is therefore a |
172 |
good thing. |
173 |
|
174 |
> Not convinced on the sub-optimal use case being the only one, either. |
175 |
> |
176 |
> Strongly objecting on the grounds that it is not something that should |
177 |
> be an EAPI issue. |
178 |
> |
179 |
> |
180 |
> unpack has to handle more types |
181 |
> =============================== |
182 |
> |
183 |
> Would be nice to get a QA warning when unpacking .lzma, .xz, etc that |
184 |
> need a build depend for the unpacker and don't have it yet. Then sounds |
185 |
> fine. |
186 |
But you don't want unpack fail on unknown types? Seems a bit |
187 |
inconsequent. |
188 |
|
189 |
> |
190 |
> |
191 |
> |
192 |
> In separate threads: |
193 |
> * Slot operator support |
194 |
> * dohard being deprecated |
195 |
> |
196 |
> |
197 |
> Did I miss anything? |
198 |
> I'm not even sure anymore where to find a list of items that is current |
199 |
> for what's on the table for EAPI-3 right now... |
200 |
> |
201 |
The PMS. (just do "emerge pms" for an up-to-date version). |