Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 834600 - Ignore collisions if target symlink owned by same package
Summary: Ignore collisions if target symlink owned by same package
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 564428 815118 834503
  Show dependency tree
 
Reported: 2022-03-05 08:00 UTC by Sam James
Modified: 2025-01-15 17:40 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-05 08:00:56 UTC
Right now, Portage can't handle overwriting a symlink with a directory, even if it knows that the package installed said symlink (no risk of overwriting something from the user then).

PMS says:
1) "Ebuilds must not attempt to merge a directory on top of any existing file that is not either a directory or a symlink to a directory." [0]
2) "Ebuilds must not attempt to merge a regular file on top of any existing file that is not either a regular file or a symlink to a regular file." [1]

The first bug I remember hitting this is android-studio (bug 815118) but I'm sure there's been some before that.

I don't think there were any substantial objections to this idea in that bug, other than it not being an immediate solution for that package given it needed to be implemented & propagate to users (and the same is true for Squid now).

[0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-14000013.2
[1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-14300013.3
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-05 08:01:56 UTC
To be clear: Portage currently will reject replacing a symlink to a directory with a directory and vice-versa, but it looks like it'd be valid for it to introspect whether the package owns both and do the replacement itself if so.
Comment 2 Pacho Ramos gentoo-dev 2022-05-26 16:44:28 UTC
I also have hit this some times, I see also some ebuilds in the tree workarounding the problem by removing the directory at pkg_preinst phase :/
Comment 3 Richard Gray 2025-01-15 17:33:06 UTC
This also affects coreutils, which is probably more of a worry for everyone.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2025-01-15 17:33:44 UTC
(In reply to Richard Gray from comment #3)
> This also affects coreutils, which is probably more of a worry for everyone.

I'm not sure how it does. We're not doing any replacements between symlinks and directories there.
Comment 5 Richard Gray 2025-01-15 17:38:45 UTC
I'm rather confused myself. I'll post more detail when I'm (more-or-less) up and running. I'm in the middle of a rebuild right now. Since everything seems to be converging on /usr/bin/ these days, I'll probably try removing the symlinks temporarily just to appease portage and have in intact installation tree.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2025-01-15 17:40:31 UTC
I suggest filing a bug (or perhaps better, going on IRC to #gentoo) and showing full output. Sounds like possibly botched merge-usr conversion.