Simon Wilkinson wrote: > [...] > > Assuming we go with hcrypto, the issue becomes one of source code > management. Sadly, we can't use git submodules for this, because doing > so would require pulling in the whole Heimdal tree to compile OpenAFS. > > What I'd like to propose is that we pull in release version of hcrypto > into src/thirdparty/hcrypto. The only commits that would be permitted > into this portion of the tree are ones which take hcrypto from a later > Heimdal release, and update our local copy. That is, any native > modifications we require to hcrypto would have to be made upstream. > > Comments?
To make it incredibly clear that our copy of hcrypto is in fact readonly and not part of the OpenAFS distribution, I would almost prefer that we create a separate repository for the third party components and pull them in as sub-modules from that git repository. Heimdal does not care about history the same way that OpenAFS does. If Heimdal ever does decide to split hcrypto out into a separate project, it would be nice for us to be able to simply redirect future OpenAFS builds against the new repository. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
