In bug 835778, we hit a failure on a binpkg consumer because vala_setup was called unconditionally. There's other examples of this in the tree. Should vala_setup be a no-op for binpkgs or should all consumers be adapted to only call for non-binpkgs? If the latter, we should mention this in eclassdocs.
Having a MERGE_TYPE conditional in a non-phase function seems a little strange. Maybe we could say in the documentation that vala_setup should be called from src_prepare.
(In reply to Ulrich Müller from comment #1) > Having a MERGE_TYPE conditional in a non-phase function seems a little > strange. Maybe we could say in the documentation that vala_setup should be > called from src_prepare. That's a fair strike against that. eclassdoc sounds better then.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=568d17e75c85695747fdbc0a84f93125fec7614c commit 568d17e75c85695747fdbc0a84f93125fec7614c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-06 19:12:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-06 19:12:59 +0000 sys-apps/fwupd: call vala_prepare in src_prepare to avoid binpkg use It's ambiguous whether vala_prepare is supposed to do anything for binpkg merges, but the convention has been to just shove it in to src_prepare for now, so let's do that to avoid trying to find Vala for binpkg installs. Bug: https://bugs.gentoo.org/837857 Bug: https://bugs.gentoo.org/837965 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/fwupd/fwupd-1.7.7-r2.ebuild | 5 ++++- sys-apps/fwupd/fwupd-1.8.3.ebuild | 4 +++- sys-apps/fwupd/fwupd-1.8.4.ebuild | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-)
