| Summary: | sys-devel/gcc-8.2.0-r5 - file collision in /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir with no claimed ownership | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michal Jakubowski <kajanos> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | minor | CC: | dev-portage, kajanos, sam, slyfox, ulm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=244518 https://bugs.gentoo.org/show_bug.cgi?id=587316 https://bugs.gentoo.org/show_bug.cgi?id=323213 https://bugs.gentoo.org/show_bug.cgi?id=899898 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | gcc-build-logs.tar.bz2 | ||
|
Description
Michal Jakubowski
2018-12-02 16:18:11 UTC
* Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). There is no problem if you simply drop 'collision-protect' from FEATURES. Assigning toolchain just in case this leftover is a symptom of anything. One: * If portageq reports that only one package owns a file then do * NOT file a bug report. Two: * And once again, please do NOT file a bug report * unless you have completely understood the above message. * * package sys-devel/gcc-8.2.0-r5 NOT merged * * Detected file collision(s): * * /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). Three: Do not file a bug report. These files are owned nowadays:
$ qfile /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/*
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/cpp.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gcc.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/cppinternals.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gccinstall.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gccint.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libquadmath.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libgomp.info)
sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libitm.info)
But I have a few orphans that look unexpected:
$ qfile -o /usr/share/gcc-data/x86_64-pc-linux-gnu/*/info/*
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info/dir
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info/dir.old
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info/dir.old
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.6/info/dir
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.6/info/dir.old
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info/dir
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info/dir.old
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info/dir
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info/dir.old
/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir
I wonder if prepman used to produce unowned 'dir' files which was fixed accidentally in:
https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/toolchain.eclass?id=c3277200aee40cf90d32221e7ec776f41c61443c
I'll have a closer look.
As a workaround you can manually remove all orphan files reported by:
$ qfile -o /usr/share/gcc-data/x86_64-pc-linux-gnu/*/info/*
I see portage's lib/portage/util/_info_files.py does 'dir' / 'dir.old' handling. CCing dev-portage@ in case it's a known problem. The dir and dir.old files are generated by emerge before it exits, for every directory in INFOPATH. It's never been considered a problem, it's just the expected behavior. FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK. (In reply to Zac Medico from comment #5) > The dir and dir.old files are generated by emerge before it exits, for every > directory in INFOPATH. It's never been considered a problem, it's just the > expected behavior. Aha. Is it added to package's CONTENTS as well? I wonder why I don't have old files uninstalled. Might be a leftover from times when I used paludis (paludis did not like to uninstall files which contents did not match vdb checksums). > FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK. Interesting. I never had FEATURES="noinfo" set and yet I had the orphans. Do you know if prepinfo had similar effect whet was not a no-op? I ran into this on fresh install moving from amd64 to ~amd64 (during the gcc upgrade). Not sure when or where the file came from. I just rm'd it and resumed since it wasn't owned. (In reply to Sergei Trofimovich from comment #6) > (In reply to Zac Medico from comment #5) > > The dir and dir.old files are generated by emerge before it exits, for every > > directory in INFOPATH. It's never been considered a problem, it's just the > > expected behavior. > > Aha. Is it added to package's CONTENTS as well? I wonder why I don't have > old files uninstalled. Might be a leftover from times when I used paludis > (paludis did not like to uninstall files which contents did not match vdb > checksums). It's not added to CONTENTS. Multiple packages can install info files in the same directory, so how would we decide which package "owns" the dir file? > > FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK. > > Interesting. I never had FEATURES="noinfo" set and yet I had the orphans. If you never had FEATURES="noinfo" set, the orphans are expected for any directory included in INFOPATH. Note that FEATURES="collision-protect" is not enabled by default, so it's not a problem with default configuration. (In reply to Zac Medico from comment #8) > (In reply to Sergei Trofimovich from comment #6) > > (In reply to Zac Medico from comment #5) > > > The dir and dir.old files are generated by emerge before it exits, for every > > > directory in INFOPATH. It's never been considered a problem, it's just the > > > expected behavior. > > > > Aha. Is it added to package's CONTENTS as well? I wonder why I don't have > > old files uninstalled. Might be a leftover from times when I used paludis > > (paludis did not like to uninstall files which contents did not match vdb > > checksums). > > It's not added to CONTENTS. Multiple packages can install info files in the > same directory, so how would we decide which package "owns" the dir file? Oh, is the below a gcc ebuild bug then? Or a portage bug? $ qlist sys-devel/gcc | fgrep info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/3.3.6/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.4/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.4/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir gcc has INFOPATH only for one active gcc in /etc/env.d. Should we change to all gccs? But even that does not seem to be enough to avoid /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into CONTENTS. Should I remove files manually? (In reply to Sergei Trofimovich from comment #9) > Oh, is the below a gcc ebuild bug then? Or a portage bug? I think it's best if we allow portage to create the info dir files, for consistency with other packages that install info files in directories like /usr/share/info that are shared with other packages. > $ qlist sys-devel/gcc | fgrep info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/3.3.6/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.4/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.4/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir > > gcc has INFOPATH only for one active gcc in /etc/env.d. Should we change to > all gccs? There's an alternative INFODIR variable that portage supports, so maybe use that if it's preferable to adding them all to INFOPATH. > But even that does not seem to be enough to avoid > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > CONTENTS. Should I remove files manually? Yes. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d266c61788fe8457e0ed0d7674bcb5d963692e8c commit d266c61788fe8457e0ed0d7674bcb5d963692e8c Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-12-04 09:05:17 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-12-04 11:05:57 +0000 toolchain.eclass: drop info/dir index, bug #672408 As explained by Zac in #672408 prepinfo() was used to drop 'info/dir' index to allow portage regenerate it. gcc package does not always install 'info/dir' files (USE-dependent). This causes nondeterminism for 'info/dir' to be owned or be an orphan file. This change drops 'info/dir' unconditionally to avoid owned/orphan collisions and always make it an orphan file. Reported-by: Michal Jakubowski Bug: https://bugs.gentoo.org/672408 Bug: https://bugs.gentoo.org/587316 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 8 ++++++++ 1 file changed, 8 insertions(+) (In reply to Zac Medico from comment #10) > There's an alternative INFODIR variable that portage supports, so maybe use > that if it's preferable to adding them all to INFOPATH. Both variables are populated throught env.d, right? As I understand in general case that means that 'dir' orphans will always be left when package is uninstalled along with env.d entry. Because portage will run INFO rebuilding too late. Is my understanding correct? > > But even that does not seem to be enough to avoid > > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > > CONTENTS. Should I remove files manually? > > Yes. Thanks! Added 'dir' file deletion consistently into gcc ebuilds now. Would be nice if portage would keep those paths through package metadata and would act on those paths when: - any files are merged into those paths -> regenerate 'dir' files - any entries are added/removed to this magic path list -> regenerate/delete 'dir' files (In reply to Sergei Trofimovich from comment #12) > (In reply to Zac Medico from comment #10) > > There's an alternative INFODIR variable that portage supports, so maybe use > > that if it's preferable to adding them all to INFOPATH. > > Both variables are populated throught env.d, right? As I understand in > general case that means that 'dir' orphans will always be left when package > is uninstalled along with env.d entry. Because portage will run INFO > rebuilding too late. Is my understanding correct? The uninstall code for bug 323213 evaluates INFOPATH and INFODIR and the beginning of the unmerge operation, so it should include INFOPATH and INFODIR settings from the package being unmerged: https://gitweb.gentoo.org/proj/portage.git/commit/?id=3acce846c43eed7feefd3ab9c47dd172a83ae1db > > > But even that does not seem to be enough to avoid > > > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > > > CONTENTS. Should I remove files manually? > > > > Yes. > > Thanks! Added 'dir' file deletion consistently into gcc ebuilds now. > > Would be nice if portage would keep those paths through package metadata and > would act on those paths when: > - any files are merged into those paths -> regenerate 'dir' files > - any entries are added/removed to this magic path list -> regenerate/delete > 'dir' files It should be doing that stuff already. The regeneration happens before emerge exits, and things are deleted during unmerge. (In reply to Larry the Git Cow from comment #11) > This change drops 'info/dir' unconditionally to avoid owned/orphan > collisions and always make it an orphan file. This doesn't look right. Why should the dir file be an orphan, when it clearly belongs to the package? IIUC Portage will only flag a problem with FEATURES=collision-protect, which is neither the default nor a setting that is generally recommended. Maybe we should turn the logic around: - Have Portage only regenerate the dir in the top-level /usr/share/info (because it is shared by many packages). - Packages should be responsible to install dir files in their info directories, which will avoid orphan files. AFAICS only toolchain packages and Emacs install GNU Info files outside /usr/share/info, in order to avoid issues with slotting. Is this still a problem? (In reply to Andreas K. Hüttel from comment #15) > Is this still a problem? Apparently not. |
