1 |
Hi there, Ladislav in particular! |
2 |
|
3 |
On 19.02.2010 13:14, Ladislav Laska wrote: |
4 |
> Yes, but that's not the problem. You see, the commit you're mentioning |
5 |
> removes hack, but another hack is still present in kde-meta, which |
6 |
> prevents prepare from base.eclass to be invoked (another "dummy" |
7 |
> function). Removing this, only src_prepare in ebuild or in base.eclass |
8 |
> can be invoked, both of them will do just fine. |
9 |
|
10 |
I originally committed 9704c7d47bbf70ec8f3fd78fd3b00e7603dfa879 but I |
11 |
fear I missed kde-meta. Thanks for noticing that, and fixing it in |
12 |
ac08ab0978dd2fc7f7b078480c1c3ca5d547e058 |
13 |
|
14 |
> Unfortunately, src_prepare is eapi=2 thing, so we have to migrate all |
15 |
> packages with patches to eapi 2, but this should not be a problem, |
16 |
> since i've seen someone is already doing that. |
17 |
|
18 |
I think you are wrong here: base_src_unpack will call base_src_prepare |
19 |
for older EAPIs. So if we can ensure that every eclass delegates to |
20 |
base_src_prepare in the end, or to something that does handle PATCHES, |
21 |
then everything should be all right. |
22 |
|
23 |
> Anyway, I'll commit patch which will at least fix things for eapi 2. |
24 |
|
25 |
Do you mean 477d925cbe9096c75c88ef1dea0b74c666ffd363 and friends? I must |
26 |
confess, I don't fully understand your intention here. We currently have |
27 |
the following code in kde_src_unpack: |
28 |
|
29 |
[[ -d "${KDE_S}" ]] || base_src_unpack unpack |
30 |
... |
31 |
# Check for PATCHES in EAPI=0|1 |
32 |
case ${EAPI:-0} in |
33 |
0|1) |
34 |
if [[ -n ${PATCHES} ]]; then |
35 |
[[ -d "${KDE_S}" ]] || base_src_prepare |
36 |
fi |
37 |
;; |
38 |
esac |
39 |
|
40 |
The base_src_unpack invokation makes sense: unpack unless the source dir |
41 |
already exists. base_src_unpack will call base_src_prepare as explained |
42 |
above, so in my opinion, that additional code further down shouldn't |
43 |
ever be necessary, unless an ebuild decides to unpack archives by |
44 |
itself, in which case it is in my opinion responsible for patching as |
45 |
well, e.g. by using base_src_unpack for unpacking. |
46 |
|
47 |
But what I understand even less is the condition. Prepare if the source |
48 |
dir still does not exist after unpacking??? What's the sense here? |
49 |
Seeing that the first thing base_src_prepare does is cd into $S, that |
50 |
doesn't seem to make a lot of sense for the $KDE_S == $S case. And for |
51 |
other cases, I still doubt that patching $S will create the $KDE_S dir. |
52 |
|
53 |
Please explain your rationale, or remove that case...esac code if you |
54 |
added it in error. If you were working on a particular package when |
55 |
writing that code, let me know what it was, and have a look at a build |
56 |
with ECLASS_DEBUG_OUTPUT=on to see whether that code you added was |
57 |
actually used the way you expected it to. |
58 |
|
59 |
Greetings, |
60 |
Martin |