1 |
On P, 2009-04-12 at 20:59 +0100, Ciaran McCreesh wrote: |
2 |
> I've got the EAPI 3 branch for PMS more or less ready: |
3 |
> |
4 |
> http://github.com/ciaranm/pms/tree/eapi-3 |
5 |
> |
6 |
> The provisional included feature list is everything that was ready |
7 |
> before the deadline. |
8 |
> |
9 |
> Before the next Council meeting (ideally a week before, so we've got |
10 |
> time to get the questions worked out), I'd appreciate it if every |
11 |
> Council member could go through each item on the list below, check its |
12 |
> description in PMS (Appendix E has a handy list of links to the |
13 |
> relevant text, or look for the boxed labels in the margin) and |
14 |
> provisionally mark it as one of: |
15 |
> |
16 |
> * critical: EAPI 3 needs to be held up until this feature is in Portage. |
17 |
> |
18 |
> * yes: This feature should be in EAPI 3, but can be dropped if it turns |
19 |
> out it's going to take ages to get into Portage. |
20 |
> |
21 |
> * no: This feature shouldn't be in EAPI 3. |
22 |
> |
23 |
> * whatever: You have no strong opinion on whether this feature should |
24 |
> be in EAPI 3. |
25 |
> |
26 |
> * query: You have questions about this feature, or you think parts of |
27 |
> it need discussion, or you've found a mistake in the PMS draft. |
28 |
> |
29 |
> I'll try to address any queries as they come so people can update their |
30 |
> opinions. |
31 |
> |
32 |
> I'd also appreciate any review of wording features from anyone else. |
33 |
> There are probably still a few holes. |
34 |
> |
35 |
> Hopefully we can get a final list decided upon and provisionally |
36 |
> approved by the next Council meeting, and then as soon as Portage is |
37 |
> ready to go we can merge everything into PMS proper and get a signed |
38 |
> approval tag as we did for EAPI 2. |
39 |
> |
40 |
> Here's the list: |
41 |
> |
42 |
> * PKG-PRETEND |
43 |
|
44 |
critical |
45 |
|
46 |
> * SLOT-OPERATOR-DEPS |
47 |
|
48 |
query. |
49 |
Needs discussion I can't conduct on-list today anymore (middle of night |
50 |
already) as I need to sit down and think this through more heavily, also |
51 |
in light of some recent discussion with dev-zero. Will bring to list |
52 |
ASAP. Mostly relates to syntax considerations. |
53 |
|
54 |
An outstanding problem to me as a package maintainer is the lack of |
55 |
means to know which slot the PM actually picked for the package, as some |
56 |
of my co-maintained packages have no use of := if it can't know which |
57 |
version was picked to act accordingly in src_configure. |
58 |
|
59 |
> * USE-DEP-DEFAULTS |
60 |
|
61 |
critical |
62 |
|
63 |
> * DEFINED-PHASES |
64 |
|
65 |
yes. critical for PKG-PRETEND |
66 |
|
67 |
> * PROPERTIES |
68 |
|
69 |
yes |
70 |
|
71 |
> * SRC-INSTALL |
72 |
|
73 |
query/yes; but the default src_install maybe shouldn't be doing the file |
74 |
exists and is greater than zero check, because dodoc in portage already |
75 |
does that. Maybe formalize that and leave that check for dodoc |
76 |
responsibility and don't bother checking twice? |
77 |
|
78 |
> * CONTROLLABLE-COMPRESS |
79 |
|
80 |
yes |
81 |
|
82 |
> * DODOC |
83 |
|
84 |
yes |
85 |
|
86 |
> * DOINS |
87 |
|
88 |
query. Lacks specification of what "correct" is in "must correctly |
89 |
handle symlinks when installing recursively", so can't judge. |
90 |
Yes, I know a mail thread addressed it, but that doesn't count in what |
91 |
goes into an approved PMS. |
92 |
I suppose it's mostly understood what it means, but it wouldn't hurt for |
93 |
a specification to be explicit. |
94 |
Also, would be interesting to know what sanity checks one would want to |
95 |
apply in the future for absolute path symlinks in case they do not start |
96 |
with $EPREFIX (don't honor --prefix)? Just curious for the future on |
97 |
this one. |
98 |
|
99 |
> * ANY-USE |
100 |
|
101 |
no |
102 |
|
103 |
> * BANNED-COMMANDS |
104 |
|
105 |
no for dohard |
106 |
whatever for dosed |
107 |
|
108 |
dohard works fine now in portage when it technically can. The wording in |
109 |
section 12.3.3 for dohard should be changed however to not give a |
110 |
guarantee but a "best effort", as if when installed on the _live system_ |
111 |
they end up on a separate partition it is not technically possible. |
112 |
However a common use case can be to do it in the same directory and it |
113 |
should work fine then, if PM makes sure the hard link is not lost when |
114 |
they get potentially copied/moved around between various partition in |
115 |
$PORTAGE_TMPDIR, $D and $ROOT, which portage does since a few months |
116 |
now. |
117 |
This best effort support already needs to exist to handle cases like |
118 |
dev-util/git provided hard links in $libexec/git-core, so this is just a |
119 |
function to do the same in ebuilds. |
120 |
|
121 |
I already wrote about this on 9th April in the "Ideas for a (fast) |
122 |
EAPI=3" thread, but got no replies. |
123 |
|
124 |
|
125 |
> * DOEXAMPLE |
126 |
|
127 |
no. perhaps after a "query" phase might lean more towards "whatever" |
128 |
|
129 |
Additionally the PMS draft has a typo: |
130 |
|
131 |
newinclude |
132 |
As above, for doexample. Only in EAPIs listed in table 12.7 |
133 |
|
134 |
newinclude is listed twice; that one should be titled newexample |
135 |
|
136 |
|
137 |
> * DOINCLUDE |
138 |
|
139 |
no |
140 |
|
141 |
> * UNPACK-EXTENSIONS |
142 |
|
143 |
yes (query), if we are sure we can rely on the xzdec arguments and such |
144 |
to remain the same once released. |
145 |
|
146 |
> * ECONF-OPTIONS |
147 |
|
148 |
query |
149 |
--disable-dependency-tracking has other implications than it being |
150 |
allowed to be passed to ./configure or not - such as dependency tracking |
151 |
being, well, disabled and the affects of that in face of any outside |
152 |
influences to headers used by it from the system, when compared to the |
153 |
case when dependency tracking is enabled. Such as when a separate |
154 |
(possibly parallel) install step kicks in. |
155 |
Olivier Crête also has an outstanding comment about a maintainer |
156 |
possibly not wanting that disabled in case of patches applied. Could use |
157 |
some elaboration on that thought, or comments in replies. |
158 |
|
159 |
--enable-fast-install is completely new to me for consideration under |
160 |
EAPI-3. Maybe I just missed it when reading PMS draft before, and it |
161 |
wasn't listed in the other summaries. |
162 |
It is libtool specific and already the default. |
163 |
Don't see any reason to specify this, as only configure's with libtool |
164 |
usage (LT_INIT in configure.ac) have that option, and enabling it is the |
165 |
default unless package upstream has specifically disabled it with an |
166 |
option to LT_INIT m4 macro. Therefore a definite "no" for |
167 |
--enable-fast-install. |
168 |
|
169 |
> * PKG-INFO |
170 |
|
171 |
query |
172 |
Same question as Petteri |
173 |
but also what if we want to display information based on saved |
174 |
environment? Any suggestion into the spec which way to use for checking |
175 |
if the package in question is already installed or not? |
176 |
|
177 |
> * PROFILE-IUSE-INJECTION |
178 |
|
179 |
query. need to review a bit further for myself in relation to profile |
180 |
set implicit stuff and emerge --newuse behaviour and output |
181 |
|
182 |
> * AA |
183 |
|
184 |
whatever |
185 |
|
186 |
> * KV |
187 |
|
188 |
whatever |
189 |
|
190 |
> * REPLACE-VERSION-VARS |
191 |
|
192 |
query |
193 |
need to think more through for myself, also possibly somewhat in |
194 |
relation to slot operators |
195 |
|
196 |
> * S-WORKDIR-FALLBACK |
197 |
|
198 |
whatever |
199 |
|
200 |
> * UNPACK-IF-COMPRESSED |
201 |
|
202 |
query |
203 |
I think the spec draft reads that it will be an error to pass regular |
204 |
files to unpack --if-compressed. That seems backwards. |
205 |
Still a bit unsure about the default non-argument case choice. |
206 |
|
207 |
|
208 |
> * RDEPEND-DEPEND |
209 |
|
210 |
yes |
211 |
|
212 |
> * DIE-ON-FAILURE |
213 |
|
214 |
whatever |
215 |
|
216 |
> * NONFATAL |
217 |
|
218 |
whatever |
219 |
|
220 |
-- |
221 |
Mart Raudsepp |
222 |
Gentoo Developer |
223 |
Mail: leio@g.o |
224 |
Weblog: http://planet.gentoo.org/developers/leio |