Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 699798 - Have a way to have non-orphan mutable files.
Summary: Have a way to have non-orphan mutable files.
Status: RESOLVED DUPLICATE of bug 371735
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi 699588
  Show dependency tree
 
Reported: 2019-11-11 08:36 UTC by Sergei Trofimovich
Modified: 2019-12-16 13:01 UTC (History)
4 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 Sergei Trofimovich gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 2019-11-11 21:01:10 UTC
Install them, so they're recorded as owned by that ebuild.
Comment 4 Mike Gilbert gentoo-dev 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 2019-12-16 13:01:03 UTC

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