I think repoman should have a check ensuring that all used USE_EXPAND flags are properly globally described/listed in profiles/desc.
Ping. This is a real problem, so is there any chance to have this implemented?
Looking at the code, it seems like this case is already supposed to be handled, otherwise the check for missing local USE descriptions (GLEP 56) would report such flags.
Repoman grabs the USE_EXPAND descriptions here: https://gitweb.gentoo.org/proj/portage.git/tree/repoman/lib/repoman/repos.py?h=repoman-2.3.16#n249 If it didn't do that, the corresponding flags would trigger an IUSE.invalid error.
dev-libs/nettle is an example package suffering from this. Repoman is happy about it.
(In reply to Michał Górny from comment #4) > dev-libs/nettle is an example package suffering from this. Repoman is happy > about it. It's happy because cpu_flags_x86_sha is described in dev-libs/nettle/metadata.xml, and cpu_flags_x86_aes is described in profiles/desc/cpu_flags_x86.desc.
(In reply to Zac Medico from comment #5) > (In reply to Michał Górny from comment #4) > > dev-libs/nettle is an example package suffering from this. Repoman is happy > > about it. > > It's happy because cpu_flags_x86_sha is described in > dev-libs/nettle/metadata.xml, and cpu_flags_x86_aes is described in > profiles/desc/cpu_flags_x86.desc. It shouldn't be because not having it in *.desc violates PMS.
For the purposes of this check, does PMS define where the list of valid USE_EXPAND prefixes come from? Obviously we could use base/make.defaults, but I don't see anything about that in PMS.
I guess profiles/desc/*.desc is probably the best source of truth for USE_EXPAND prefixes.
It comes from the currently active profile. Which means it must be present in all profiles that are applicable to package in question (i.e. filtered by keywords).
(which means it'd be a good idea to loop over all profiles, and complain if any of them doesn't have the relevant USE_EXPAND, compared to desc/)
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
