1 |
It seems like a simple before/after comparison of active useflags and the text |
2 |
of the src_* functions (skipping build and install if they are completely |
3 |
identical) should catch the majority of unnecessary rebuilds. |
4 |
|
5 |
On 25 July 2014 13:36 Ian Stakenvicius wrote: |
6 |
> On 25/07/14 01:15 PM, Andreas K. Huettel wrote: |
7 |
> > |
8 |
> >>> Maybe this could be solved by having two kinds of revisions: - |
9 |
> >>> One would rebuild all as usually (for example, -r1...) - The |
10 |
> >>> other one would only regenerate VDB and wouldn't change the |
11 |
> >>> installed files (for example, -r1.1) |
12 |
> >>> |
13 |
> >>> But I am not sure if it could be viable from a "technical" |
14 |
> >>> point of view :( |
15 |
> >> |
16 |
> >> I'm afraid it couldn't. The major problem is not knowing *when* |
17 |
> >> to migrate metadata, portage usually gets that right. The problem |
18 |
> >> is in getting the correct output which is often near to |
19 |
> >> impossible. |
20 |
> > |
21 |
> > I think we'd appreciate some more information here: |
22 |
> > |
23 |
> > * What exactly is the metadata that we're talking about? * How much |
24 |
> > of it can be generated by sourcing the ebuild, without running |
25 |
> > phases? * When does that exactly break? Example? |
26 |
> > |
27 |
> |
28 |
> It may help this overall discussion to step back even further here: |
29 |
> |
30 |
> * What do we want to accomplish, exactly? |
31 |
> |
32 |
> - allow portage to emerge updated packages without rebuilding them |
33 |
> (ie running src_* and pkg_*inst phases), when it can be determined |
34 |
> from metadata changes (or for -rX.Y method perhaps it is assumed |
35 |
> -just- on filename changes) that this is not necessary. |
36 |
> |
37 |
> * What are all of the cases that would validly trigger this |
38 |
> dont-bother-to-run-phases shortcut? |
39 |
> |
40 |
> - addition of missing dependency [1] |
41 |
> - new useflag not enabled by default |
42 |
> - removed useflag that was not previously enabled |
43 |
> - changing of dependency atom(s) -- ie swapping a specific atom to |
44 |
> virtual one |
45 |
> - EAPI bump (maybe??) |
46 |
> - .... <-- add more please! |
47 |
> |
48 |
> |
49 |
> * For each of the above, in what cases is a full rebuild probably |
50 |
> necessary anyhow?? |
51 |
> |
52 |
> - dependency atom minimum version is increased, and the in-VDB version |
53 |
> of this dep is too old (??) |
54 |
> - new dependency atom is missing from VDB (??) |
55 |
> - EAPI bump adds new entries to VDB that need to be calculated from |
56 |
> say, merge phase |
57 |
> - .... |
58 |
> |
59 |
> |
60 |
> |
61 |
> ..i think from there we can perhaps determine what metadata could be |
62 |
> updated and/or needs to be updated to maintain consistency in the |
63 |
> dont-rebuild cases we want. |
64 |
> |