People keep asking where do /lib64/libgcc_s.so.1 and /usr/bin/gcc come from. My pipe dream is to have a gentoo system with 0 orphan files. In this bug I will focus on /bin, /lib and /usr/bin, /usr/lib. Examples: - bug #699588: /lib64/libgcc_s.so.1 is a library copy of active gcc, can't bet tracked as-is by gcc ebuild. gcc-config ebuild woud be a good place. - /usr/bin/gcc is a symlink of active gcc, can't be tracked by gcc or gcc-config ebuild - numerous files in 'qfile -o /bin/* /usr/lib*/*': $ qfile -o /bin/* /usr/lib*/* | wc -l 142 I'm not sure of an exact mechanism. The vague outline: - have a way to declare mutable file in ebuild itself. say, an eclass helper similar to 'dobin/doexe' - store it in vdb as a normal file - have a mark ${somewhere} that it's ok if vdb checksum does not match actual contents - uninstalling a package should delete such a file - installing/upgrading a package should not modify installed file (unless pkg_*() phase does it explicitly as a side-effect)
Just own them in one ebuild, make all GCCs depend on it and add a postrm() to it to clean them up when the last consumer is uninstalled (if desirable).
(In reply to Michał Górny from comment #1) > Just own them in one ebuild, make all GCCs depend on it and add a postrm() > to it to clean them up when the last consumer is uninstalled (if desirable). I don't understand what you mean by "own" here.
Install them, so they're recorded as owned by that ebuild.
I guess you mean something like this? src_install() { use split-usr && dosym /dev/null /lib64/libgcc_s.so.1 } pkg_postinst() { gcc-config "$(gcc-config -c)" }
(In reply to Michał Górny from comment #3) > Install them, so they're recorded as owned by that ebuild. I see a few immediate problems: 1. This breaks checksum validation in CONTENTS and tools start complaining about checksum mismatch. On top of that paludis (I think) just left the file on disk as it did not match CONTENTS entry. 2. The semantics of installing a new version is not clear to me. I guess the file gets overwritten and you need to go out of your way (in pkg_preinst()?) to preserve previous instance of a file.
Yes, something like this. But use at least preinst to have the valid actually valid. You want hacky stuff, you expect hacky results.
`CONFIG_PROTECT` mechanism feels very close to a solution. The main difference from `CONFIG_PROTECT` for this use case would be: - [on package install/update/uninstall] not to leave new file around as a backup when existing file exists and differs from installed. Example file would be a /bin/sh symlink.
*** This bug has been marked as a duplicate of bug 371735 ***
