so I have a package that manually depends on go via:
and it does not get rebuilt with @golang-rebuild. ionen dug up that this set is populated by ebuilds that inherit go-related eclasses. So it should rather check the DEPEND/BDEPEND on go either.
Also I have a feeling if a package conditionally depend on go, via USE flag, it does not get populated to this set either.
I'll need to think about this, but all packages that use go to build
should inherit a go-related eclass. I can't think of a reason that a
package should depend on go without inheriting a go-related eclass.
I think this is a Portage issue, the set was introduced in Portage for bug 752153:
Author: Georgy Yakovlev <firstname.lastname@example.org>
Date: Fri Oct 16 12:43:54 2020 -0700
cnf/sets/portage.conf: add new sets for go rebuilding go packages
go-built binaries may contain security
vulnerabilities if a binary built with vulnerable compiler.
go is known to embed vulnerable code to all binaries it builds, if
vulnerability was present in the compiler or one of standard libraries.
This commit adds `golang-rebuild` set, which allows easy
rebuild of most go-compiled system packages.
simple 'emerge @golang-rebuild' should rebuild everything affected.
a prompt to run this command can be added to postinst message in
Signed-off-by: Georgy Yakovlev <email@example.com>
Signed-off-by: Zac Medico <firstname.lastname@example.org>
diff --git a/cnf/sets/portage.conf b/cnf/sets/portage.conf
index 0d11d7891..22f0fa3a5 100644
@@ -103,3 +103,9 @@ class = portage.sets.dbapi.UnavailableBinaries
# to the matching portdb entry.
class = portage.sets.dbapi.ChangedDepsSet
+# Installed packages that inherit from known go related eclasses.
+class = portage.sets.dbapi.VariableSet
+variable = INHERITED
+includes = golang-base golang-build golang-vcs golang-vcs-snapshot go-module
See bug 865114 for some additional fun related to this bug...
(In reply to J. Paul Reed from comment #3)
> See bug 865114 for some additional fun related to this bug...
Grr, I meant bug 865115.