Portage should not fetch binaries for packages with patches present in /etc/portage/category/pn/* when getbinpkg is enabled, as these features are inherently incompatible, and the presence of user patches leaves no doubt as to the user's intention. This is exacerbated by bug 463964, requiring user-patched packages to be merged on their own with --getbinpkg=n, making it difficult to maintain a system that uses binary packages while still applying user patches to some. Reproducible: Always Steps to Reproduce: 1. Enable getbinpkg 2. Create one or more patches in /etc/portpage/patches 3. Emerge anything Actual Results: Binary packages are fetched for packages we've explicitly provided patches for. Expected Results: The binary is ignored in favour of a source build that applies patches.
(In reply to Ben Torkington from comment #0) > Portage should not fetch binaries for packages with patches present in > /etc/portage/category/pn/* when getbinpkg is enabled, as these features are sorry: /etc/portage/patches/category/pn
We could do this by including the metadata in the binpkgs and the Packages index, but it's not trivial. It *would* be doable to say "okay, we won't do getbinpkg if the user asks us not to, for the cases where /etc/portage/patches matches it", but note that /etc/portage/patches has a bunch of specifications it supports. I also feel like someone will inevitably want a way of handling this with new /etc/portage/patches invalidating a binpkg overall, but I take your point and I think it's a fair one.
