Bug 699798 – Have a way to have non-orphan mutable files.

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description Sergei Trofimovich (RETIRED) 2019-11-11 08:36:01 UTC]

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)

[Comment 1 Michał Górny 2019-11-11 09:26:00 UTC]

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).

[Comment 2 Sergei Trofimovich (RETIRED) 2019-11-11 20:03:30 UTC]

(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.

[Comment 3 Michał Górny 2019-11-11 21:01:10 UTC]

Install them, so they're recorded as owned by that ebuild.

[Comment 4 Mike Gilbert 2019-11-11 21:59:33 UTC]

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)"
}

[Comment 5 Sergei Trofimovich (RETIRED) 2019-11-11 22:11:00 UTC]

(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.

[Comment 6 Michał Górny 2019-11-12 06:27:49 UTC]

Yes, something like this.  But use at least preinst to have the valid actually valid.

You want hacky stuff, you expect hacky results.

[Comment 7 Sergei Trofimovich (RETIRED) 2019-11-12 08:35:35 UTC]

`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.

[Comment 8 Michał Górny 2019-12-16 13:01:03 UTC]

*** This bug has been marked as a duplicate of bug 371735 ***