app-admin/setools DEPENDs and RDEPENDs on dev-qt/qtchooser. This dependency is very unusual and probably wrong, only qt packages should depend on it (or users can emerge it explicitly if they use it as part of their development environment). Please explain why the dependency was added. If it's legitimate, please consider putting a comment about it somewhere in the ebuild. Thanks.
The dep is not needed. There was a call towards qcollectiongenerator and was associated with qtchooser. But the dependency towards PyQt5 is sufficient (and needed). setools is bumped to 4.0.1 (upstream made a new release recently with a small change in it regarding icons) with this change in place. I also updated the dependency towards libsepol to libsepol-2.5 as this is needed for setools-4. Currently, setools-4 is still without keywords as it is not fully compatible with setools-3 (upstream decision) and we will need to wait until the depending packages are updated with the setools-4 specific calls in them.
(In reply to Sven Vermeulen from comment #1) > The dep is not needed. There was a call towards qcollectiongenerator and was > associated with qtchooser. But the dependency towards PyQt5 is sufficient > (and needed). qtchooser is just a "dispatcher" between qt4 and qt5, it should never be depended upon. The actual qcollectiongenerator binary is installed by dev-qt/qthelp. That would be the correct dependency. Btw, note that if the package build system calls /usr/bin/qcollectiongenerator directly, that's a bug because there's no guarantee on which version will be invoked. In this case you can add a workaround to the ebuild by exporting QT_SELECT=[4|5], but the bug should be reported upstream. > setools is bumped to 4.0.1 (upstream made a new release recently with a > small change in it regarding icons) with this change in place. I also > updated the dependency towards libsepol to libsepol-2.5 as this is needed > for setools-4. > > Currently, setools-4 is still without keywords as it is not fully compatible > with setools-3 (upstream decision) and we will need to wait until the > depending packages are updated with the setools-4 specific calls in them. Thanks. Would you mind updating -9999 as well?
(In reply to Davide Pesavento from comment #2) > (In reply to Sven Vermeulen from comment #1) > > The dep is not needed. There was a call towards qcollectiongenerator and was > > associated with qtchooser. But the dependency towards PyQt5 is sufficient > > (and needed). > > qtchooser is just a "dispatcher" between qt4 and qt5, it should never be > depended upon. The actual qcollectiongenerator binary is installed by > dev-qt/qthelp. That would be the correct dependency. > > Btw, note that if the package build system calls > /usr/bin/qcollectiongenerator directly, that's a bug because there's no > guarantee on which version will be invoked. In this case you can add a > workaround to the ebuild by exporting QT_SELECT=[4|5], but the bug should be > reported upstream. It *can* call qcollectiongenerator to re-generate the help files. They have already been generated tho in the repo so the dep is only needed if we want to re-generate which we dont actually do. > > setools is bumped to 4.0.1 (upstream made a new release recently with a > > small change in it regarding icons) with this change in place. I also > > updated the dependency towards libsepol to libsepol-2.5 as this is needed > > for setools-4. > > > > Currently, setools-4 is still without keywords as it is not fully compatible > > with setools-3 (upstream decision) and we will need to wait until the > > depending packages are updated with the setools-4 specific calls in them. > > Thanks. Would you mind updating -9999 as well? I will double check the QT_SELECT stuff and update -9999. I dont think it requires regenerating either but will confirm. If setup.py exports QT_SELECT itself is that correct? or should the build system be directly calling a different binary?
(In reply to Jason Zaman from comment #3) > I will double check the QT_SELECT stuff and update -9999. I dont think it > requires regenerating either but will confirm. If setup.py exports QT_SELECT > itself is that correct? or should the build system be directly calling a > different binary? The build system must not use QT_SELECT, that's just a hack/workaround. It should call the actual binary using its (version-specific) full path. I think you can use `$$[QT_INSTALL_BINS]/qcollectiongenerator` in a qmake-based build system.
9999 was fixed in commit 0dca6e6accc0f97f70dd4d8a364e39664ca49ea5
