Currently this file does not belong to any package, but since it is actually installed by one of the ebuilds (qt-core I presume) it should be under portage control and should be installed first to ${D}
I confirm this bug.
(In reply to comment #0) > Currently this file does not belong to any package, but since it is actually > installed by one of the ebuilds (qt-core I presume) it should be under > portage control and should be installed first to ${D} Actually no... gentoo-qconfig.h is regenerated in pkg_post{inst,rm}() for every x11-libs/qt-* ebuild, since it changes depending on which Qt modules are installed. Thus installing it to ${D} will result in a conflict at merge-time, because e.g. qt-gui will try to overwrite the file previously installed by qt-core. However we could do the following: 1) qt-core installs an empty gentoo-qconfig.h during src_install() via doins, so that it ends up in CONTENTS. 2) every qt-* ebuild (including qt-core) generates the correct content of gentoo-qconfig.h in pkg_postinst() and overwrites the file in ${ROOT}. 3) when qt-core is unmerged, the file mtime and checksum won't match, however portage will unmerge it anyway because FEATURES=unmerge-orphans is enabled by default. This still won't work if unmerge-orphans is disabled, but I believe that only a very very small subset of users disable it. Do you think the above solution could work? Any other ideas?
Thank you for the detaild explanation. Since the file may be generated by different packages I agree that it makes things much more complicated. Is it possible to add a comment in the begiing of the file stating that was autgenerated and installed by some ebuild? at least there is going to be a notification that it was installed by portage. If that's not possible I believe the bug should be marked as WONTFIX.
Sure, that's doable. It's C header file after all, so it would just be a matter of adding /* Auto-generated by qt4-build.eclass */ or something like that at the top of the file. Anyway, I think the solution I outlined above is an improvement over the current situation, so I'm inclined to implement it. During the transition period, we need to handle systems which have FEATURES=collision-protect instead of protect-owned too. Another (much simpler but also dirtier) solution would be to run "rm -f gentoo-qconfig.h" in qt-core's pkg_postrm().
I like the idea of x11-libs/qt-core installing an empty header file.
I'm going to implement this in qt5-build.eclass for Qt5 first, to see if it works well in practice, and later I'll backport it to qt4-build.eclass.
This is fixed for Qt 5, and since Qt 4 is dead there's no point putting in the work to backport it.
