1 |
On Fri, Mar 04, 2022 at 12:01:42AM +0000, Sam James wrote: |
2 |
> |
3 |
> |
4 |
> > On 4 Mar 2022, at 00:00, William Hubbs <williamh@g.o> wrote: |
5 |
> > |
6 |
> > On Wed, Mar 02, 2022 at 09:32:14PM +0500, Anna Vyalkova wrote: |
7 |
> >> On 2022-03-01 15:55, William Hubbs wrote: |
8 |
> >>> I am willing to flag EGO_SUM as deprecated if a variable can be flagged |
9 |
> >>> as deprecated; that is what I'm looking up now. |
10 |
> >> |
11 |
> >> EGO_SUM is often the only choice for overlays, so consider not |
12 |
> >> deprecating it. |
13 |
> > |
14 |
> > EGO_SUM does not work for large SRC_URI; that is the reason it is |
15 |
> > being deprecated. |
16 |
> > |
17 |
> > Also, my understanding is we do not normally keep code around |
18 |
> > if that code's only purpose is to support overlays. |
19 |
> |
20 |
> I don't think there's a need to rip it out given we know it can be quite |
21 |
> useful there though, right? |
22 |
> |
23 |
> It's not actively harming anything to just keep the small amount of code there. |
24 |
|
25 |
Sure, it may not be harmful to keep it there, but using it in the main |
26 |
tree isn't going to be a thing. |
27 |
|
28 |
> I think it's quite a nice convenience option (in fact, for ::gentoo too), where |
29 |
> EGO_SUM isn't huge. But I admit this isn't that common. |
30 |
|
31 |
Another thing to consider is that the bulk of the code in the eclass is |
32 |
for handling EGO_SUM, so if I can remove it, ultimately, it will mean less code to maintain. |
33 |
|
34 |
I will post a separate patch which I will not merge at this point to |
35 |
show what I'm talking about. |
36 |
|
37 |
Thanks, |
38 |
|
39 |
William |