Re: [gentoo-dev] don't rely on dynamic deps

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 01:36 PM, 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.
>

I forgot: [1] since the package has merged prior to this anyhow,
whatever dependency it was must have been installed already when this
package was emerged.  So if it can still be found in vdb then we
should be safe to add the dependency to vdb of this package, otherwise
we may need to trigger a rebuild.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPSllcACgkQ2ugaI38ACPCL3QD+ITe3bzJrJIORniniY9rzTEd5
W5nmL5zB+HiZuMZKdZQA/jrn88lx8bfn/f6DetPdrYiFjjShcXoeMbh5nCNmtcz9
=LEAi
-----END PGP SIGNATURE-----