Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 398497 - /usr/include/qt4/Gentoo/gentoo-qconfig.h should be under package manager control
Summary: /usr/include/qt4/Gentoo/gentoo-qconfig.h should be under package manager control
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Low enhancement (vote)
Assignee: Qt Bug Alias
Depends on:
Reported: 2012-01-11 09:17 UTC by Vladimir Berezhnoy
Modified: 2017-12-22 12:38 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Berezhnoy 2012-01-11 09:17:39 UTC
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}
Comment 1 Thomas Bettler 2012-03-28 22:09:45 UTC
I confirm this bug.
Comment 2 Davide Pesavento (RETIRED) gentoo-dev 2012-04-15 15:34:42 UTC
(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?
Comment 3 Vladimir Berezhnoy 2012-04-15 16:23:35 UTC
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.
Comment 4 Davide Pesavento (RETIRED) gentoo-dev 2012-04-15 16:48:17 UTC
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().
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2012-04-15 17:45:32 UTC
I like the idea of x11-libs/qt-core installing an empty header file.
Comment 6 Davide Pesavento (RETIRED) gentoo-dev 2012-06-12 21:21:39 UTC
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.
Comment 7 Michael Palimaka (kensington) gentoo-dev 2017-12-22 12:38:27 UTC
This is fixed for Qt 5, and since Qt 4 is dead there's no point putting in the work to backport it.