| 1 |
>>>>> On Sun, 8 Jun 2014, Rich Freeman wrote: |
| 2 |
|
| 3 |
>> b) failglob in global scope |
| 4 |
>> Bug #463822 |
| 5 |
|
| 6 |
> I'm a bit concerned that this one could be a cure worse than the |
| 7 |
> disease - unintended side-effects/etc. A repoman check seems a lot |
| 8 |
> less likely to cause problems. |
| 9 |
|
| 10 |
Any specific example of a side effect that you have in mind? I believe |
| 11 |
that there are none in global scope, but maybe we shouldn't extend the |
| 12 |
feature to function scope. |
| 13 |
|
| 14 |
>> 4. Features rejected from EAPI 5 |
| 15 |
|
| 16 |
> Ok, I suspect we're going to spend about 95% of the time on these. |
| 17 |
|
| 18 |
Yes. ;-) |
| 19 |
|
| 20 |
>> a) Patch applying function in package manager |
| 21 |
>> Bug #463768 |
| 22 |
>> - Needed for 2d) and 4b) |
| 23 |
>> - This will duplicate epatch() from eutils, in simplified form. |
| 24 |
>> - Name "eapply" has been suggested. |
| 25 |
|
| 26 |
> My two cents. Keep an eclass for the fancy stuff, but move into the |
| 27 |
> EAPI a few basic patch functions: |
| 28 |
|
| 29 |
> 1. Application of a patch file, defaulting to -p1, allowing override |
| 30 |
> of -p level, but without auto-detection. |
| 31 |
> 2. Application of a directory full of patch files in lexical order, |
| 32 |
> again supporting override of -p level without auto-detection. |
| 33 |
|
| 34 |
> I'm not a big fan of either auto-detection or forcing patch re-writes |
| 35 |
> to be -p1 always. |
| 36 |
|
| 37 |
This more or less agrees with the status of the discussion: |
| 38 |
https://bugs.gentoo.org/show_bug.cgi?id=463768#c32 |
| 39 |
|
| 40 |
We haven't decided yet if there should be autodetection, but I'd also |
| 41 |
prefer a -p1 default without autodetection. There's always epatch if |
| 42 |
you need anything more fancy. |
| 43 |
|
| 44 |
>> b) User patches |
| 45 |
>> Bug #475288 |
| 46 |
>> - Needs 4a) |
| 47 |
>> - Current wording of the spec requires that every ebuild must |
| 48 |
>> include a call to the function in src_prepare, which is |
| 49 |
>> controversial. |
| 50 |
>> - Names "apply_user_patches" or "eapply_user" have been suggested. |
| 51 |
|
| 52 |
> I'm generally fine with it (we can bikeshed the name to death later), |
| 53 |
> but is there any reason to not just simply apply the patches after |
| 54 |
> src_prepare is done and not make maintainers call it? If we're |
| 55 |
> concerned about sequencing with other activities in src_prepare then |
| 56 |
> that is fine - I don't have a big problem with it being a fatal error |
| 57 |
> if it doesn't get called. |
| 58 |
|
| 59 |
IMHO the package manager shouldn't perform any operations between |
| 60 |
src_* phases, outside of phase functions. Therefore, the user patch |
| 61 |
function should be called either from src_prepare, or from a phase |
| 62 |
function (src_userpatch?) newly introduced. |
| 63 |
|
| 64 |
I'd strongly dislike a new phase function, but conceptionally, it |
| 65 |
would still be much cleaner than doing some magic after src_prepare. |
| 66 |
|
| 67 |
My suggestion would be to add the user patch function to |
| 68 |
default_src_prepare, plus a policy that the function must be called if |
| 69 |
an ebuild (or eclass) contains an explicit src_prepare(). The latter |
| 70 |
could be enforced by repoman. |
| 71 |
|
| 72 |
>> c) EJOBS variable |
| 73 |
>> Bug #273101 |
| 74 |
>> - Discussion was in 2008. Is there (still) consensus? |
| 75 |
|
| 76 |
> Assuming anybody still wants to implement this, I see no reason to |
| 77 |
> keep bikeshedding this. EJOBS fits the bill. |
| 78 |
|
| 79 |
> The only thing that might be worth noting is that distcc users may |
| 80 |
> have an interest in distinguishing between gcc jobs and everything |
| 81 |
> else. I once messed with dictcc with very high job numbers and it |
| 82 |
> worked great when make hit a directory full of .c files, and not so |
| 83 |
> great when make/ant/whatever tried to run 50 instances of java in |
| 84 |
> parallel. |
| 85 |
|
| 86 |
I don't have a strong opinion about this one. |
| 87 |
|
| 88 |
However, my general advice would be not to impose work on PMS and |
| 89 |
package manager teams, for features that nobody is pushing any longer. |
| 90 |
|
| 91 |
>> d) Source eclasses only once |
| 92 |
>> Bug #422533 |
| 93 |
|
| 94 |
> Does anybody still want this included? It seems to me like the list |
| 95 |
> discussion was leading in a different direction, but it isn't 100% |
| 96 |
> clear to me if this is the case. |
| 97 |
|
| 98 |
Right, discussion has died down. Many eclasses now use a mechanism |
| 99 |
equivalent to the one in C header files, which seems to do the job. |
| 100 |
|
| 101 |
>> e) HDEPEND: host dependencies for cross-compilation |
| 102 |
>> Bug #317337 |
| 103 |
|
| 104 |
> It isn't 100% clear to me which of the 14 proposed solutions in that |
| 105 |
> bug is the final answer, but I think it is DEPEND becomes target |
| 106 |
> depends, and HDEPEND is introduced as host depends. |
| 107 |
|
| 108 |
> Is the final intent that if HDEPEND isn't defined, then |
| 109 |
> HDEPEND=DEPEND, or does HDEPEND=""? |
| 110 |
|
| 111 |
We did RDEPEND=${DEPEND} once and it was a mistake. So I think default |
| 112 |
HDEPEND should be empty. |
| 113 |
|
| 114 |
Ulrich |
Archives