1 |
Hello, |
2 |
|
3 |
just what I had in mind. Works just fine with everything I tested - good job. |
4 |
|
5 |
Regards Ladislav Laska |
6 |
S pozdravem Ladislav Laska |
7 |
--- |
8 |
xmpp/jabber: ladislav.laska@××××××.cz |
9 |
|
10 |
|
11 |
|
12 |
On Sat, Feb 20, 2010 at 11:02 AM, Martin von Gagern |
13 |
<Martin.vGagern@×××.net> wrote: |
14 |
> Hi there! |
15 |
> |
16 |
> On 19.02.2010 22:23, Ladislav Laska wrote: |
17 |
>> Hello again, |
18 |
>> |
19 |
>> I have decided to continue discussion in new thread. This discussion |
20 |
>> was started in thread "kde-sunset: kdepim-kresources broken". |
21 |
>> |
22 |
>> I have replaced my code with what I originally intended (the code in |
23 |
>> git is wrong, since I made a mistake editing it - here is what I |
24 |
>> intended): |
25 |
>> |
26 |
>> # Check for PATCHES in EAPI=0|1 |
27 |
>> case ${EAPI:-0} in |
28 |
>> 0|1) |
29 |
>> if [[ -n ${PATCHES} ]] && [[ -d "${KDE_S}" ]]; then |
30 |
>> base_src_prepare |
31 |
>> fi |
32 |
>> ;; |
33 |
>> esac |
34 |
>> |
35 |
>> Look, for example, at kde-base/ark ebuild. There is a patch, but it's |
36 |
>> not applied correctly without my code. |
37 |
> |
38 |
> media-gfx/gwenview-1.4.2-r3, on the other hand, would try applying |
39 |
> patches twice /with/ your code. |
40 |
> |
41 |
>> What I'm worried about is the check [[ -d "${KDE_S}" ]] makes sure, |
42 |
>> that this code is called if |
43 |
>> |
44 |
>> [[ -d "${KDE_S}" ]] || base_src_unpack unpack |
45 |
>> |
46 |
>> did not called base-src_unpack and therefore did not applied patches. |
47 |
>> |
48 |
>> There are two problems with EAPI=0|1 |
49 |
>> |
50 |
>> 1) It depends on file naming and will not work if base_src_unpack |
51 |
>> unpacks into $KDE_S |
52 |
> |
53 |
> You mean kde-meta_src_unpack does unpack into $KDE_S, right? |
54 |
> |
55 |
> I just had a look. For kde-base/ark, kde-meta_src_unpack does unpack |
56 |
> part of the tarball, therefore kde_src_unpack won't call |
57 |
> base_src_unpack, therefore base_src_prepare won't get called either. |
58 |
> |
59 |
>> 2) Even if base_src_unpack calls base_src_prepare, we're adding |
60 |
>> patches automatically after this call, but they will not be applied. |
61 |
> |
62 |
> You're right, there is code collecting additional patches from $PATCHDIR |
63 |
> into the $PATCHES array. So we need to call base_src_prepare /after/ |
64 |
> that, while the current base_src_unpack call comes before that, and |
65 |
> unpacking has to come before that as $PATCHDIR is unpacked as well. |
66 |
> |
67 |
> As base_src_unpack calls base_src_prepare unconditionally for recent |
68 |
> incarnations of base.eclass, I feel we cannot call base_src_unpack at |
69 |
> all. Instead we should simply call "unpack ${A}" directly, and |
70 |
> base_src_prepare later on. |
71 |
> |
72 |
> I feel that this code collecting and applying $PATCHES would be better |
73 |
> suited to a kde_src_prepare than kde_src_unpack, but I'm not sure it's |
74 |
> worth refactoring kde.eclass. |
75 |
> |
76 |
>> Since I can't think of correct check, please let me know if you have |
77 |
>> an idea. Also, let me know if I'm wrong about something and it's not |
78 |
>> needed at all. (but I doubt that, because ark, as mentioned above, is |
79 |
>> counterexample) |
80 |
> |
81 |
> No, you are correct in diagnosing the problem. I just had another stab |
82 |
> at a solution. Have a look at 5979aefafa6e200a09d5dd7b3a6e99b3e0a9d74e |
83 |
> and see if you find any package where that approach doesn't work. |
84 |
> |
85 |
> Greetings, |
86 |
> Martin |
87 |
> |
88 |
> |