-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPSlY0ACgkQ2ugaI38ACPBDHAD+POgCJlbPv9HHwhK4wxd8b2ir ywM71Aemu6SPfCTE2MIBAKATag94jCHLlqwkYN2jrW23tYqTi5ajOwLzoZ/EqHx0 =qUpY -----END PGP SIGNATURE-----
