Multi-instance packages status report

[Edward Z. Yang]

Excerpts from Joachim Breitner's message of 2014-07-22 08:23:22 +0100:
> [Replying to the list, in case it was sent to me in private by accident]

Oops, thanks.

> thanks for the explanations, it makes it clear to me.
> 
> Do the package key contain the flags used to compile dependencies? In
> the example where it could matter the flag would change that package’s
> key, so maybe it is redundant....

That is a good question. At the moment, flags are not incorporated, but
they could be.  I think it probably makes more sense to include them,
but it does require accommodation from the dependency solver which
doesn't exist at the moment.

> And just to confirm my understandn: If we had a completely reproducible
> environment, the same key would (conceptually, not practically) imply
> the same IPID, right?

I don't even think that's necessary conceptually true.  If I am working
on a package in development and I modify the type of one file, the
package key (as currently described) stays the same, but the ABI hash
changes.  I think the overwrite behavior can still be handy in
development situations since it avoids the "lots of old packages"
problem that the GSoC project had to deal with.  Conversely, I don't
think the package key should include something like the hash of the
sources of the source tree, because it is totally possible for differing
sources to be ABI compatible (and thus have the same IPID).  But what
this points to is the need to differentiate between ABI (not unique)
and "true IPID" (which is absolutely, completely unique).

Edward