Created attachment 467002 [details, diff] hack hack % cat metadata/layout.conf use-manifests = false (with no source files downloaded yet) # ebuild firefox-52.0.ebuild fetch !!! Fetched file: firefox-52.0.source.tar.xz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: MD5 RMD160 SHA1 SHA256 SHA512 WHIRLPOOL (with the source files downloaded) # ebuild firefox-52.0.ebuild manifest >>> Skipping creating Manifest for /usr/local/overlays/mikachu/www-client/firefox; repository is configured to not use them # ebuild firefox-52.0.ebuild unpack !!! Fetched file: firefox-52.0.source.tar.xz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: MD5 RMD160 SHA1 SHA256 SHA512 WHIRLPOOL The attached patch seems to restore the intended behavior but i have no idea about any of the code, i just copied stuff from the part that prints the error message for the manifest command.
I feel like "use-manifests = false" is intended for transition from thick to thin manifests, and that DIST entries containing digests for distfiles should always be required (otherwise we've got a security problem due to execution of unverified code fetched over a network). The use-manifests attribute was implemented in this commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=f3101b3adce6731790f80f83fafece54b7bd8a63 That commit refers to this issue, which discusses a transition from thick to thin manifests: https://code.google.com/archive/p/chromium-os/issues/11308
You probably just want to set "thin-manifests = true" in metadata/layout.conf. Using a google search for "use-manifests = false", I found some expanded documentation from the author of the patch: use-manifests = [ false | true | strict ] Defaults to strict if unspecified. This provides per repository control as to whether manifests should be used/generated; if set to false, manifest usage and generation is disabled for that repository. If set to true, this directs the package manager to use manifest data if available, but to not consider it a failure if a manifest file is missing. Additionally, if set to true, the package manager will generate manifests by default. This mode is primarily of use for migrating a repository that lacked manifests, to using/requiring manifests. Finally, if set to strict, manifests are generated/required and it’s considered a failure if the data isn’t available. Generally speaking, there rarely is any reason to set this option to anything other than strict.
