Currently, if 'manifest-hashes' specifies a hash that is not supported by Portage at the moment, Portage silently ignores it and generates Manifest without that hash. I don't think this is really desired. Given that we're going to enable SHA3 soon, and it requires additional dependencies on python<3.6, this means that some developers will accidentally commit stripped down Manifests. I think the better behavior in this case would be to error out, and request the developer to upgrade Portage or install missing deps appropriately.
Actually, it is supposed to do that but it does not account for hash implementations possibly missing. I've sent a patch for that to the ml.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=7857c1cae45c3cbd51f6eb0827ccc9bd17ff7269 commit 7857c1cae45c3cbd51f6eb0827ccc9bd17ff7269 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2017-11-06 07:08:53 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2017-11-06 14:33:01 +0000 Replace static MANIFEST2_HASH_FUNCTIONS with dynamic list Remove the MANIFEST2_HASH_FUNCTIONS const and replace it with (deduplicated) calls to get_valid_checksum_keys(). We want Portage to always complain whenever one of the hashes is not available even if it is technically supported by the specific Portage version. Closes: https://bugs.gentoo.org/634812 Reviewed-by: Zac Medico <zmedico@gentoo.org> man/portage.5 | 4 ++-- pym/portage/const.py | 3 --- pym/portage/manifest.py | 6 +++--- pym/portage/repository/config.py | 5 +++-- repoman/pym/repoman/repos.py | 3 ++- 5 files changed, 10 insertions(+), 11 deletions(-)
