Re: Multi-instance packages status report
[Replying to the list, in case it was sent to me in private by accident] Hi Edward, Am Montag, den 21.07.2014, 23:25 +0100 schrieb Edward Z.Yang:
Excerpts from Joachim Breitner's message of 2014-07-21 21:06:49 +0100:
maybe a stupid question, but how does the package key relate to the hash that "ghc-pkg" shows for package?
Fine question---this is definitely something that is different from the GSoC project. The short answer is, the current hash shown in ghc-pkg is the ABI hash associated with the InstalledPackageId, which is computed after GHC is done compiling your code; whereas the package key is a hash of the dependency graph, which can be done before compilation.
The longer answer is we now have three ID-like things, in order of increasing specificity:
Package IDs: containers-0.9 These are the "user visible" things that we expect users to talk about in Cabal file Package Keys: md5("containers-0.9" + transitive deps) These are the identifiers the compiler cares about: they are used for type equality, and contain a bit more detail than we expect a user to normally need---however, a user might need to refer to this to disambiguate in some situations. Installed Package IDs: ABI hash of compiled code This uniquely identifies an installed package in the database, up to ABI.
So, if two packages have the same IPID, their package keys are guaranteed to be the same, but not vice versa. (And likewise for package IDs.)
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.... 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? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
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
On 22/07/14 08:23, Joachim Breitner wrote:
[Replying to the list, in case it was sent to me in private by accident]
Hi Edward,
Am Montag, den 21.07.2014, 23:25 +0100 schrieb Edward Z.Yang:
Excerpts from Joachim Breitner's message of 2014-07-21 21:06:49 +0100:
maybe a stupid question, but how does the package key relate to the hash that "ghc-pkg" shows for package?
Fine question---this is definitely something that is different from the GSoC project. The short answer is, the current hash shown in ghc-pkg is the ABI hash associated with the InstalledPackageId, which is computed after GHC is done compiling your code; whereas the package key is a hash of the dependency graph, which can be done before compilation.
The longer answer is we now have three ID-like things, in order of increasing specificity:
Package IDs: containers-0.9 These are the "user visible" things that we expect users to talk about in Cabal file Package Keys: md5("containers-0.9" + transitive deps) These are the identifiers the compiler cares about: they are used for type equality, and contain a bit more detail than we expect a user to normally need---however, a user might need to refer to this to disambiguate in some situations. Installed Package IDs: ABI hash of compiled code This uniquely identifies an installed package in the database, up to ABI.
So, if two packages have the same IPID, their package keys are guaranteed to be the same, but not vice versa. (And likewise for package IDs.)
(Replying to Edward) It's not clear to me why identical IPID would imply identical package key. Can't two instances of a package compiled against different dependencies still have identical ABIs? Reviewing your patches is next on my queue... Cheers, Simon
Excerpts from Simon Marlow's message of 2014-07-22 12:27:46 +0100:
(Replying to Edward)
It's not clear to me why identical IPID would imply identical package key. Can't two instances of a package compiled against different dependencies still have identical ABIs?
No, because the package key is baked into the linker symbols (and thus the ABI). I guess maybe if you had a completely empty package, the ABIs would be the same. Cheers, Edward
On 22/07/14 13:17, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of 2014-07-22 12:27:46 +0100:
(Replying to Edward)
It's not clear to me why identical IPID would imply identical package key. Can't two instances of a package compiled against different dependencies still have identical ABIs?
No, because the package key is baked into the linker symbols (and thus the ABI). I guess maybe if you had a completely empty package, the ABIs would be the same.
Aha, I see. Thanks! Simon
participants (3)
-
Edward Z. Yang -
Joachim Breitner -
Simon Marlow