It seems like a simple before/after comparison of active useflags and the text of the src_* functions (skipping build and install if they are completely identical) should catch the majority of unnecessary rebuilds.
On 25 July 2014 13:36 Ian Stakenvicius wrote: > On 25/07/14 01:15 PM, Andreas K. Huettel wrote: > > > >>> Maybe this could be solved by having two kinds of revisions: - > >>> One would rebuild all as usually (for example, -r1...) - The > >>> other one would only regenerate VDB and wouldn't change the > >>> installed files (for example, -r1.1) > >>> > >>> But I am not sure if it could be viable from a "technical" > >>> point of view :( > >> > >> I'm afraid it couldn't. The major problem is not knowing *when* > >> to migrate metadata, portage usually gets that right. The problem > >> is in getting the correct output which is often near to > >> impossible. > > > > I think we'd appreciate some more information here: > > > > * What exactly is the metadata that we're talking about? * How much > > of it can be generated by sourcing the ebuild, without running > > phases? * When does that exactly break? Example? > > > > It may help this overall discussion to step back even further here: > > * What do we want to accomplish, exactly? > > - allow portage to emerge updated packages without rebuilding them > (ie running src_* and pkg_*inst phases), when it can be determined > from metadata changes (or for -rX.Y method perhaps it is assumed > -just- on filename changes) that this is not necessary. > > * What are all of the cases that would validly trigger this > dont-bother-to-run-phases shortcut? > > - addition of missing dependency [1] > - new useflag not enabled by default > - removed useflag that was not previously enabled > - changing of dependency atom(s) -- ie swapping a specific atom to > virtual one > - EAPI bump (maybe??) > - .... <-- add more please! > > > * For each of the above, in what cases is a full rebuild probably > necessary anyhow?? > > - dependency atom minimum version is increased, and the in-VDB version > of this dep is too old (??) > - new dependency atom is missing from VDB (??) > - EAPI bump adds new entries to VDB that need to be calculated from > say, merge phase > - .... > > > > ..i think from there we can perhaps determine what metadata could be > updated and/or needs to be updated to maintain consistency in the > dont-rebuild cases we want. >
signature.asc
Description: This is a digitally signed message part.
