When a package is being upgraded/downgraded, pkg_postinst() will be invoked before invocation of pkg_postrm(), so e.g. `qconfig_add_option ${option}` will be invoked before `qconfig_remove_option ${option}` and eventually ${option} will be removed. PMS 10.2 Call Order ... The call order for upgrading or downgrading a package is: • pkg_setup • src_unpack • src_compile • src_test (except if RESTRICT=test) • src_install • pkg_preinst • pkg_postinst • pkg_prerm for the package being replaced • pkg_postrm for the package being replaced
hmm, any thoughts on what we should do? should I have the pkg_postinst() add a second copy and have pkg_postrm() just remove one so that in the end we end up with the right amount?
I noticed this a few weeks ago, too. What about a solution where you not only add the option to the file, but also set a environment variable, that you've added it. qconfig_add_option() { local option=$1 qconfig_remove_option $1 sed -i -e "s:QT_CONFIG +=:QT_CONFIG += ${option}:g" /usr/share/qt4/mkspecs/qconfig.pri ADDED_${option}=1 } qconfig_remove_option() { local option=$1 if [[ ADDED_${option}=0 ]]; then sed -i -e "s: ${option}::g" /usr/share/qt4/mkspecs/qconfig.pri fi ADDED_${option}=0 } Would that work? I didn't (yet) test this, even if it works, maybe there is a better solution.
Created attachment 144677 [details, diff] qt-config.patch This is the patch we intend to commit with the next qt-4.4 snapshot to fix this. It installs a qconfig.pri file in mkspecs/gentoo/ for each package in src_install() and generates mkspecs/gconfig.pri based on those files in pkg_post{inst,rm}(). This solution was chosen because it seems less error prone than has_version() hackery. Setting an env var won't work because env vars set in pkg_postinst() will be reloaded in post_rm()... For all package managers using proper environment restoration (i.e. portage > 2.1.4 as well as paludis and pkgcore) there will be an issue with pkg_postrm() from the uninstalled package being run last during upgrading causing this bug to manifest itself until all 4.4.0_rc1 packages have been uninstalled or upgraded. Solutions to this include: Uninstalling before upgrading. Reinstalling qt-core (or any package that sets QCONFIG_ADD) after having upgraded all of them. Running write_qconfig() manually (with QCONFIG_ADD and QTDATADIR set appropriately) after having upgraded all of them. Etc... Adding blockers for this seems like overkill to me so probably the best cause of action is to just document it in pkg_postinst()...
Fixed in CVS, for beta1, using the aforementioned patch by Bo Andresen & David Leverton.
