Given the 20240330 version/date cpuid's bdepend on app-arch/gzip instead of app-alternatives/gzip is plausibly deliberate, but if so, one would expect some sort of note in the ebuild to that effect. Meanwhile, on a system without app-arch/gzip (and app-alternatives/gzip USE=pigz, with a no-files null-package app-arch/gzip that cpuid seems to be the last package pulling in, that I'd love to be rid of), I can confirm that cpuid still extracts/builds/merges just fine, so if the app-arch/gzip bdep really *is* deliberate, it needs an explanatory comment even /more/.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=76b0532b33c9730bf9b8aa05ba80a68753b898d2 commit 76b0532b33c9730bf9b8aa05ba80a68753b898d2 Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2024-04-14 12:55:59 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2024-04-14 12:57:12 +0000 sys-apps/cpuid: switch to app-alternatives/gzip Closes: https://bugs.gentoo.org/929975 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> sys-apps/cpuid/{cpuid-20230614.ebuild => cpuid-20230614-r1.ebuild} | 4 ++-- sys-apps/cpuid/{cpuid-20240330.ebuild => cpuid-20240330-r1.ebuild} | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
[ Something (spam-filter?) ate the close notification email and I missed it. Comment to trigger another email which I'll hopefully get this time so it'll actually appear closed in my email client, too. ]
