Created attachment 838055 [details] emerge --info I've updated all packages on my system, but app-alternatives/tar can't be emerged. > $ sudo emerge -avuDN @world > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] app-alternatives/tar-0::gentoo USE="gnu (split-usr) -libarchive" 0 KiB > [ebuild N ] app-alternatives/cpio-0::gentoo USE="gnu (split-usr) -libarchive" 0 KiB > > Total: 2 packages (2 new), Size of downloads: 0 KiB > > Would you like to merge these packages? [Yes/No] > > >>> Verifying ebuild manifests > > >>> Emerging (1 of 2) app-alternatives/tar-0::gentoo > >>> Installing (1 of 2) app-alternatives/tar-0::gentoo > * checking 2 files for package collisions ... > * Detected file collision(s): > * > * /bin/tar Trying to see to with package /bin/tar belongs to > $ equery belongs /bin/tar > * Searching for /bin/tar ... > app-arch/tar-1.34-r2 (/bin/gtar) And re-emerging it > $ sudo emerge -av1 app-arch/tar > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] app-arch/tar-1.34-r2::gentoo USE="acl nls verify-sig xattr -minimal (-selinux)" 0 KiB > [ebuild N ] app-alternatives/tar-0::gentoo USE="gnu (split-usr) -libarchive" 0 KiB after re-emerging app-arch/tar, this command fails at alternatives/tar with the same error. A similar thing also happens for app-alternatives/cpio
Please do not truncate the collision output and share the build.log in full.
You have the unnecessarily strict "collision-protect" enabled in make.conf. It forbids even orphaned collisions.
(In reply to Sam James from comment #2) > You have the unnecessarily strict "collision-protect" enabled in make.conf. > It forbids even orphaned collisions. It's from the developer profile(!) https://github.com/gentoo/gentoo/blob/master/profiles/targets/developer/make.defaults
I have added FEATURES="-collision-protect" to my make.conf and managed to "resolve" this issue. I think I'll change my profile now as it doesn't look like a profile targeted to developers (of things other than the gentoo distribution) as I was hoping it would be. Thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6728932a980eb0ebfac0bfc0566d1dbba6ef83ea commit 6728932a980eb0ebfac0bfc0566d1dbba6ef83ea Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-01 04:47:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-01 04:48:04 +0000 profiles/targets/developer: use FEATURES="protect-owned" instead of "collision-protect" collision-protect stops orphaned collisions too which is a problem when changing ownership of a file between packages. We also recommended people stop using it in the libxcrypt news item. Closes: https://bugs.gentoo.org/883561 Signed-off-by: Sam James <sam@gentoo.org> profiles/targets/developer/make.defaults | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
I'm not convinced this was a bug. The whole point of developer profiles is to be more strict. Sure, most of them are harmless (and therefore of no concern to *regular users*) but some may be accidental and *developers* should know about them.
(In reply to Michał Górny from comment #6) > I'm not convinced this was a bug. The whole point of developer profiles is > to be more strict. Sure, most of them are harmless (and therefore of no > concern to *regular users*) but some may be accidental and *developers* > should know about them. I'm not aware of any developers using these profiles, only users accidentally using it out of confusion. As for the FEATURES setting itself: it's unsafe to have it on and it may result in broken upgrades (keep in mind that anything that interrupts a world upgrade is Not Good, and we can't guarantee a sane state if it happens, pam & pambase and anything interrupting in between is a good example, but same for Python target changes), just like it did with the libxcrypt migration.
Shouldn't these profiles be removed then?
That would work for me. Kill in 23.0?
Reverted per comment #6. This is not a bug. Also, please follow policy before making changes to a general make.defaults file, i.e. discuss it in gentoo-dev. Policy reference: https://devmanual.gentoo.org/profiles/make.defaults/index.html
(In reply to Ulrich Müller from comment #10) > Reverted per comment #6. This is not a bug. > In future, please include explanations in commit messages & tag bugs.
(In reply to Ulrich Müller from comment #10) > Also, please follow policy before making changes to a general make.defaults > file, i.e. discuss it in gentoo-dev. > > Policy reference: > https://devmanual.gentoo.org/profiles/make.defaults/index.html I don't consider it a "high-up" make.defaults file, but I agree that the future of the profiles would be worth discussing on the mailing list.
(In reply to Sam James from comment #12) > I don't consider it a "high-up" make.defaults file, targets/developer is at second level, i.e. only profiles like base and embedded are higher up. But maybe the devmanual's wording could profit from some clarification? I guess that its intention was to discuss all non-arch profile changes in the mailing list. > but I agree that the future of the profiles would be worth discussing > on the mailing list.
